[lsb-discuss] Some questions on the LSB build environment

Mike Hearn mike at theoretic.com
Thu Feb 6 15:06:28 PST 2003

> http://www.geocrawler.com/archives/3/7460/2000/11/0/4652756/
> and then there's always /.:
> http://slashdot.org/articles/01/06/30/1734253.shtml

I didn't see the first one, thanks (i was mostly checking lsb-discuss
and lsb-futures). It raises some good points, ones that I was just
thinking about in fact, which I'll touch on below. The slashdot story
wasn't all that interesting, I've seen most of the points raised there
before (i'm not knocking slashdot, but this time it wasn't all that

> Your list seems like a good start, btw.  The interactivity
> issue is an interesting one.  I can see both reasons to have
> it, and reasons not to.  (I worked at a shrinkwrap software
> company, and they loved having some UI during install.)
> IMHO some provision for bypassing the UI entirely for automated
> headless installs is a must if we eventually allow a UI.

Yes. Currently the autopackage apis look a bit like this:

selectString "somevar" "This is a label" "This is the default"

The 3 parameters are mandantory. I've simplified slightly, ie dropped
i18n, and in fact the whole UI layer is going to be overhauled soonish.
But one of the hard and fast rules is, if you ask a question, it's got
to have a good default. If the code needed to determine that default is
complicated, then so be it. You need headless installs for all kinds of
things, even other kinds of uis (to replicate appfolder style uis for

> It'd be nice to have the list whittled down to the minimum
> set of issues you think really need to be addressed...
> you weren't quite clear on whether you thought dependencies
> were a must, but I get the feeling you really do want them badly.

Yes, IMO they are a must. The LSB as it stands is fine for large
commercial apps on Linux, but I'm primarily interested in the kinds of
open source apps that we use every day, the Gimp, various gnome
utilities, kde games and so on. Typically they are quite small but link
to a lot of shared libs. Statically linking everything isn't workable
here. The way I see it presently is that the major issues that arise
with DSOs are:

1) Symbol fixup collisions. Well, I spent tonight trying (unsuccessfully
unfortunately) to setup Gentoo in VMware. I'll try with a more automated
distro next week. I have a feeling that an extension will be necessary
to work around this problem, but I don't really know yet.

2) Dependancy resolution and naming. In particular, each distro has its
own conventions for naming packages and so on, and there are at least 3
different dep resolvers I can think of (apt, urpmi, emerge). Apt of
course sits on top of another packaging format. There are outstanding
problems with all of these systems, mostly minor ones, but they need
looking at nonetheless.

3) gcc breakages (esp wrt to c++)

Issues from that geocrawler email:
   I can`t see the deb or rpm people gaining any individual benefit
   from changing, but I do believe it is in the interests of Linux to change
   things, so we`ve got to present them with a reason for co-operating to
   produce a better design. We provide the environmental pressure to help them
   evolve a better solution...
I should make it clear from the start that I don't really care about replacing RPM or DEB.
Distros can and should use whatever packaging system floats their boat. The philosophy of
autopackage is to integrate and work with the native packaging system when possible. So,
I don't think "evolving" rpm or deb should be a goal. It's certainly not one of mine.... [1]

   Your ideas only work if there is a package management API, which will most
   likely not make it into LSB 1.0.  It is a very sticky and very political
   issue, and will most likely not be resolved for a while.  Remember,
   technical superiority usually loses to practicality.
This is a real issue. Is design-by-committee really the best way to produce a solution
to this problem? I dunno. My original plan was simply to write a solution for making portable
packages that was so kickass it eventually became a de-facto standard (though it didn't 
actually rely on being popular in order to work). Slightly naive perhaps.

Obviously a solution that doesn't involve the distro makers has problems of its own,
hence the fact that I'm interested in this debate.

Personally I lean more towards the "create a new system" mindset. One possibility is simply
to say, well, if somebody can come to either the LSB or the FSG with a working solution that
everybody at least accepts, then that's what we adopt. As opposed to attempting to actually
design and build it here. But I don't know if that's a good way to do things. On the
other hand, most of the systems I've seen so far (rpm, dpkg and my own) have strong points
that could be merged. I'm not just saying that because it sounds nice, I have thought it
through and afaict it would be possible. But possible != desirable necessarily.

   If we can define a
   middleware it achieves our aim of encouraging competition in package

Such a middleware might take the form of the GNUpdate project (gnupdate.org)
which is producing APIs that abstract rpm/deb under a neutral API. Think
Java for package managers.

   You horribly confuse "standardize" and "innovate".  We are not here to
   develop new Linux technology.  We are here to standardize existing
   technology and (if we have to) adapt existing technology in the interest
   of ease of install and consistency.

Core issue here. If the LSB or FSG has a hard policy against inventing new
stuff, then I think any solution would end up being IMO sub optimal as a 
software management system. I've get to be convinced that the technologies
we have today are fully up to the task of producing portable packages.

[1] I should perhaps note how I've approached the issue up until now. 
autopackage works a bit differently to rpm or dpkg, in that it's built
 for distro portability from the start. For instance, it uses just in 
time dependancy resolution. That means each package contains scripts 
that check for the presence of each needed dependancy. If a check fails, 
another script gets control which retrives a package for that dependancy.
It can be either another autopackage, or if available apt/urpmi/emerge 
would be used, ie control is passed to the native package manager when 
possible. If it's another autopackage, then the checks for _that_ package 
are run, and so on. So, each dependancy is resolved "just in time". The
checks probe the system directly - the testForLib function for instance
scans the linker cache and LD_LIBRARY_PATH, just like ld.so would.

Contrast that with RPM and DPKG, which maintain a database of installed
packages, then resolve and calculate the dependancies all at once, at
the start. Both approaches have their pros and cons, the most obvious
pros of all-at-once being that it's fast and it lets you do things like
show progress bars, and give warnings if you don't have enough disk space.
Obviously with JIT resolution, you don't know how much work you'll have to do
in advance. On the other hand, using scripts in this way means that you
are insulated from the details of how the distro manages packages (if it does).
Hence, although more work, it is more portable.

In a nutshell, I've been building an autoconf for binaries. Sort of.
Anyway, as we all know, today configure scripts are the de facto standard
for source tarballs. They do leave a lot to be desired however, so it's worth
perhaps attempting to hammer out a better solution rather than just end up
with whatever catches on.

thanks -mike

More information about the lsb-discuss mailing list