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

[Havoc Pennington]

On Sat, 2003-10-04 at 16:29, Michael Schwendt wrote:
> > Even if we become like debian with 10,000
> > packages that won't solve the cross distribution problem.
> 
> Ah, cross-distribution. *cough* Who makes sure that app A from site B
> and lib D from site E for distribution C work smoothly on distribution
> F where inter-library dependencies are satisfied with packages from
> site G? Where is the testing and quality assurance in this scenario?
> 

The solution to end-user dependency problems is very simple, and it is
the same one used on Windows.

Here it is: don't have any dependencies that don't come with the OS.
Bundle everything internal to your app.

This is what almost all proprietary software for Linux does.

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...

For software that comes with the OS and lives in the Fedora Project, we
should be able to do better; redhat-config-packages doesn't make you see
dependencies really, and it could be made even better than it is.

Here is one way to think about it from a UI standpoint. The user model
is that there's "the application" which can be installed, uninstalled,
moved around, and launched.

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. So there are three
implementation details leaking out, where the simple user model would
have only 1 concept.

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

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

 - 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

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.

Havoc