sane dependencies -- a positive look at 'fix your packages'

[Mike Hearn]

On Sat, 2003-10-04 at 22:49, Havoc Pennington wrote:
> The solution to end-user dependency problems is very simple, and it is
> the same one used on Windows.

I've come late to this thread, blame freshers week at my university :)

Anyway, I respectfully disagree. We're in a fundamentally different
scenario to that of Win32 developers, namely that:

a) We're massively outnumbered
b) Linux users tend to have a lot more software installed than Windows
users do
c) Software is a lot more modular

Simply bundling everything with the app really is not acceptable,
especially for dialup users. Example: Gaim for Linux - RPM is 1.7mb (i
think), Gaim for Windows - self extracting EXE with GTK+ is 6.7mb

OK, so that makes little difference when you have half a megabit piped
into your house or room, but it makes all the difference for the
majority of the world who don't. Obviously Gaim is a program with few
dependencies.

Another simple example - statically linking the Jamboree gnome music
player would change the size of the binary from 600k to 24mb, which is
clearly insane.

Now, you can say "Linux is a platform, which consists of libraries A, B
and C - do not depend on anything else". That approach basically works,
but is kind of difficult to force through. One mans essential library is
anothers bloat, it may be that some libraries cannot commit to the ABI
guarantees needed etc. I have 151 packages installed with "lib" in their
name, it'd be pretty hard to get them all into even a tiered platform,
though it could be done.

> It's also what an LSB-compliant package _must_ do. But of course, nobody
> seems to make LSB-compliant packages, instead they just complain about
> how packages are distribution-dependent. ;-) People, this is the whole
> point of the LSB...

Well, have you tried to make an LSB compliant package? It is really
quite hard. For instance, a standard compile of any non-trivial C app on
RH9 will pull in the thread-local locale model stuff from glibc 2.3. 

You can use the lsb tools to statically link everything needed, but it
really does have to be *everything*, you cannot say "well everybody has
GTK, i'll skip that" - the way the tools work mean the build will fail
if you link against libraries that were not LSB compiled themselves.
That's not really intentional, it's just because ld wants to completely
close the symbol set. We figured out a way around that with apbuild, but
the LSB weren't interested of course - they *want* people to be forced
to only use their base set (they need to be able to guarantee what an
LSB app is and isn't).

Not to mention that the LSB headers are not the same as the glibc ones,
for instance I once tried to compile DBUS (i think v0.1 or something
quite old now) as an LSB app to see what it was like, but the build
failed due to obscure bugs in the LSB headers. Something to do with
sunrpc iirc, which was wierd but there you go. I should try again
sometime, as I reported the bug.

Then you have to be able to make an RPMv3 package that meets their
stringent restrictions etc...

So back to my original example, an LSB package of Jamboree would have
taken most of the day to download on a 56kbit connection, as opposed to
approx 5 mins for a non-LSB package that simply depended on the right
libraries.

> Unfortunately, for moving around and launching you're using a .desktop
> file. For install/uninstall you're using the r-c-p "comps group" concept
> sometimes, and "foo.rpm" files sometimes. 

Yes, this is not ideal. The way I was planning to tackle this (when
someday autopackage doesn't suck) was to embed package information into
the .desktop file, then teach Nautilus/Konqueror about that. They could
read the .desktop file, see that the relevant program was not installed
and perhaps gray it out to show that it'd take some time to launch
(because it'd need to be downloaded). The launcher, when clicked, takes
care of download, verification, installation, dep resolution and so on.

You could also use the launcher to uninstall, though the idea of garbage
collecting packages appeals to me in some vague way.

In this scenario you have only one concept as a user, that of "the
application" (or launcher) - you can click it, email it to friends, drop
it on a disk etc, and the details of what CPU arch and deps you have etc
are sorted out by the system.

It's kind of like the MacOS X AppFolders system UI wise, except without
the massive bloat and suckyness that accompanies a pure NeXT style
system.

> So ways to improve this might include:
> 
>  - a way to bundle a set of RPMs into a single user-visible file, 
>    so you can have an "uninstalled app" visible in the file manager

Too large for dialup users I think :(

>  - have ways to install/uninstall a package by manipulating the thing 
>    implemented now as a .desktop file (the menu/filemanager entry)

Seems the easiest way forward, though it'd be easier still if there were
standards for packaging.

>  - try to ensure packages for "end user apps" always have names that 
>    match the primary desktop file in the package; so e.g. the Gnumeric 
>    .rpm package would show up in file manager as "Gnumeric Spreadsheet"
>    and once installed you get same in menu

Kind of icky. What happens if you click an installed RPM? It'd look like
it should run the app, but then how do you remove it? It also relies on
something that could be broken quite easily (the name mapping).

> Those are just some possibilities, not well-researched proposals. The
> general idea is to fix the "leakiness" of the current abstraction;
> ideally, a naive end user doesn't have to learn 3 implementation details
> when a single concept of "an application" should be sufficient.

Right. I quite like the idea of a non-technical user browsing to
frozen-bubble.org, and seeing the icon embedded in the web page. They
drag it to the panel, or perhaps even just click it in the webpage
directly. The button starts glowing or something to indicate that the
computer is working, and the process of installation gets going in the
background. When it's done, the icon goes coloured, maybe with some
pretty sparkly effect to indicate "newness", and the program launches.

The app is now available from the menu, the web page, can be dragged to
the panel/desktop/whatever. User decides frozen bubble is really cute,
and opens up their chat program and drops the icon (the application, in
effect) into the chat window, where it appears the other end grayed out
and the process begins again. If that other user is on PowerPC and lives
the opposite end of the planet, no problems, the right download is
selected from the right mirror.

A lot of work, obviously, but all doable. First of all you need an easy
way to build distro-neutral packages. From my experiences, I'd say the
LSB is not it....

thanks -mike