[lsb-discuss] Packaging

Leibowitz, Michael michael.leibowitz at intel.com
Fri Oct 20 13:47:09 PDT 2006

For the past while I have been looking at the third party software
packaging situation on Linux with an eye on what could be done to
improve the situation for users, distros, and developers.  As it stands
now, there is no easy/uniform way to deploy software that is not shipped
by the distro on many different distros simply and reliably.  While some
partial solutions do exists, they are not robust enough to serve all
interested parties well.  From looking at the current state of things as
well as several current solutions, I came up with a list of requirements
that I felt a robust solution must have.  This list, in short is:

1) A unified and simple UI for installing/removing/updating packages
that is the same regardless of distro or desktop environment

2) Ability to detect, alert, and install updates when they are available

3) Proper interaction with the distro, including doing the RightThing
when the distro and package have a mutual interest in a file or service

4) A database of installed packages, files, and assorted
meta-information that can be queried

In crafting a solution, there seems to be two fundamentally opposing
directions that can be taken.  The first is transformation (ala alien)
where one package format can be transformed into the native package
format.  The other approach is what I call a secondary manager, where
there is a manager for the third-party packages that interlinks with the
manager for distro packages in some way.

In the transformative case, because of the mismatch of one packaging
system's capabilities to another, transformation has typically been a
lowest common denominator affair.  While this works for some simple
applications, there are many applications where this methodology simply
forces the burden onto the packagers to come up with elaborate
post-inst, and pre-inst methods to smooth over differences.  This is an
example of what I call the knowledge embedded in the package.  If a new
distro is targeted, a new version of such a package may need to be
released to deal with the idiosyncrasies of the new distro.  If we were
to construct a more robust architecture, we would like to put the
knowledge in the transformation engine, so that packagers have to do the
least work.  However, this makes writing a transformation engine fairly
difficult, as there can be major differences in packaging systems once
we go beyond the least common denominator.  Because we need to create an
abstraction of the differences to the neutral-flavor package, we end up
re-implementing a lot of packaging machinery.  In a conventional
packaging system, the package engine performs operations on the package.
However, in this situation, we are effectively inside-out, where the
package performs operation on the package engine.  The hooks to invoke
our abstracted interfaces must be transformed into the native interfaces
for the package.  Thus, all functionality must be mapped to the
respective pre and post hooks.  This can make realization of such an
architecture tricky, to say the least.

On the other side of the scale, we have the secondary approach.  This
methodology realizes what a distro-neutral package manager that is
mostly conventional in architecture.  However, the interface to the
primary manager is where the challenges lie.  In the case of a file or
service that both managers have a mutual interest in, there needs to be
some clever handling of what is to be done.  For example, if a third
party package intends on manipulating a sendmail rule (perhaps as a spam
filter), then it must behave appropriately when the distro upgrades
sendmail.  In addition, it must do the RightThing if the distro decides
to remove sendmail and install another MTA.  The RightThing is a little
ambiguous.  We could map the dependency of our third-party package on
sendmail and alert the user that removing sendmail will result in a
broken dependency or we could simply remove the third party package and
interfere less with the native manager.  The first methodology implies
directly manipulating the primary package manager's database of
meta-data and inserting fake packages and invoking the secondary
manager.  The second methodology implies merely intercepting commands to
the primary manager and performing appropriate on-the-fly fixups before
executing the primary manager's actions.

It is my opinion that the secondary approach is more elegant solution
that is more likely to succeed.  However, I also acknowledge that the
transformative solution is the currently accepted methodology by the
distro community.  I hope this forms the basis for a lively discussion
here and hope to see interested parties at the Packaging Summit on Dec 5
in Berlin.  

A more detailed version of this is available on the FSG wiki at

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

More information about the lsb-discuss mailing list