[lsb-discuss] Packaging

Theodore Tso tytso at mit.edu
Mon Oct 23 06:01:05 PDT 2006

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

More information about the lsb-discuss mailing list