[lsb-discuss] Packaging

Leibowitz, Michael michael.leibowitz at intel.com
Mon Oct 23 22:35:55 PDT 2006

I have to say that if you accept all of LSB's restrictions, that package
management is not very difficult.  It becomes difficult when things
don't fit nicely into the restrictions LSB provides.  So, if I'm
developing a simple application, I'm probably OK.  I use libraries in
the LSB way, and I am fine.  There are several cases where applications
depend on more than libraries, or where cross-vendor dependencies are

Can I make an LSB compliant PAM module?  PAM isn't specified, so I guess
I need to bundle PAM.  I could probably get away with not doing this
because ABI compatibility is generally easier for plugins.  Now, I need
to use my bundled version of PAM.  That means manipulating a bunch of
files that are not in my /opt/vendor/foobar directory.  If I understand
correctly, the LSB answer is that it is now the sysadmin's job to make
it work, and LSB cannot permit the package to automatically manipulate
the system.

What if I wanted to make a package that had a GIS data-set for a
particular GIS suite?  I'm prohibited from my packages having a
dependency on something that I don't provide.  My packages will install
without warning, but will not alert the user/admin that they are
worthless without the GIS software?  What if the GIS software has a file
format change in between versions?  Without a dependency, I can't even
alert the user/admin that this package will not work with that version
of the GIS software.

The installers do work and scratch an itch of the ISV's, which should
not be overlooked.  However, they also don't scratch the itch of admins
or distros.  Since installers don't leave behind a meta-data database,
can an admin quickly find out what third-party software they have
installed on their systems?  What if version foo of package bar has a
security vulnerability?  Can they quickly query if their machines have
version foo of package bar installed?  For distros, as soon as the
install starts writing things outside of /opt/ it is a problem.  While
in most cases, packages won't need to, but there are cases where they
will.  This is where a headache for admins comes in.

Michael Leibowitz
Software Engineer, Channel Platform Solutions Group
Intel Corporation
michael.leibowitz at intel.com
+1 503 264 7621

>-----Original Message-----
>From: lsb-discuss-bounces at lists.freestandards.org [mailto:lsb-discuss-
>bounces at lists.freestandards.org] On Behalf Of Theodore Tso
>Sent: Monday, October 23, 2006 6:01 AM
>To: Jiri Dluhos
>Cc: lsb-discuss at lists.freestandards.org
>Subject: Re: [lsb-discuss] Packaging
>I think we're running into scope creep.  There are a potentially
>infinite number of things that we can do to in order to improve on any
>packaging system --- but there are also only a few things that an
>application vendor needs, particular one who is creating a software
>product which is designed to run on an LSB-compliant system.
>First of all, as should be obvious, the details of internal package
>dependencies for packages provided by the distribution go away.  An
>LSB-compliant application is only allowed to assume that facilities
>guaranteed by the LSB will exist.  Hence, the LSB application only
>needs dependencies on packages provided by that vendor (if the vendor
>really wants to break up their product into multiple packages shipped
>together on the same CD), and on "LSB version x.y".  This simplifies
>the depenency problem immensely, and means that we do *NOT* have to
>solve the problem of abstract dependencies to deal with the problem
>that Debian uses "libssl0.9.7" whereas Red Hat uses "openssl", version
>0.9.7 (because RPM supports installing multiple packages with
>different version numbers, and dpkg does not).
>Secondly, the last time we talked to ISV's, a significant number of
>them were **not** interested in a new package manager.  The problem is
>that a many of the larger ISV's have already a huge amount of
>investment using either their own package installation system, or some
>commercial/third-party provided package installer (i.e.,
>InstallShield), and they want the "install experience" for the
>customer to be the same across all platforms --- Windows, Solaris,
>AIX, and Linux.  And they can do that today using some of these
>commercially written package management systems that use Java, for
>So for those folks, what they need is an interface to the *existing*
>package management system to inform the package management system that
>package _foo_ has been installed, and that if package _foo_ needs to
>be uninstalled, to please run the deinstaller at a particular
>pathname, which will return either an exit status of 0 if the
>deinstallation was successful (and so the package name can be removed
>from the package namespace), or 1 (if the package deinstallation was
>cancelled or failed).
>That's all that's necessary to keep those folks happy.  For bonus
>points the interface could register the list of files that the package
>installed, so that a command like "rpm -q -l" or "dpkg -L" will list
>all of the files in the package, but strictly speaking even that is
>not necessary.
>If we want to also see if there is some additional set of RPM features
>which are now commonly supported by all of the distributions using RPM
>as well as Debian/Ubuntu's Alien, and someone is willing to document
>the package *format* (which unfortunatelly the RPM developers don't do
>for us), we could expand the features that are allowed by the
>LSB-subset of the RPM packaging *format*.  But in my mind, that's
>probably a secondary priority, unless we start getting ISV's lining up
>saying that they really want to use some particular RPM packaging
>feature that requires an RPM packaging tag that isn't currently
>documented by the LSB.
>But developing a new packaging system, out of whole cloth?  That
>sounds like a research project to me.  If someone wants to try to
>design an all-singing, all-dancing new packaging format, and then try
>to get all of the distributions to adopt it, they are welcome to try.
>But it doesn't seem like a good idea to me to bet the success of the
>LSB on such an effort....
>						- Ted
>lsb-discuss mailing list
>lsb-discuss at lists.freestandards.org

More information about the lsb-discuss mailing list