Re: Package managment idea...

[Havoc Pennington <rhpennin midway uchicago edu>]

On Fri, 25 Dec 1998, Matthew Berg wrote:
> Reading through the package management discussion, there seem to be two
> camps - those who believe that Gnome should have its own package
> management system for the sake of simplified application installation,
> and those who believe that it would be wrong to impose a new format (and
> consequently, it is presumed, a completely different set of package
> management tools)  on users.

I didn't read the rest of the thread, but I am writing the Gnome Apt
frontend. gnome-apt uses the apt-pkg library by Jason Gunthorpe, which is
by far the most advanced package management system available today, at
least that I've seen. 

> What I would personally like to see would be an abstaction library that
> would allow for easy translation to a platforms native packaging
> format.  Perhaps it would even be wise to define a meta format for GNOME
> as both the standard distribution format for gnome applications and as
> the internal representation for the abstraction layer.
>

Well, there are only two formats right now that matter: rpm and dpkg. rpm
is more common, and dpkg has technical advantages (most important IMO is
that it has the features to work with Apt - don't ask me for details 'cuz
I don't know). However, almost all of Apt is written to be package-format
independent; any package format that provides the right features will work
with it I'm told, and based on the source code this looks true. Only a few
files are debian-specific. Probably someone who knew rpm well could go in
there and add rpm support without too much trouble, though they might have
to hack rpm some. 

Other package formats are either little-used (slp), little more than
tarballs (Solaris, Slackware), or source-code only (BSD ports). I don't
know about other commercial Unices (SCO, HPUX, etc.) - maybe they are
noteworthy. But I suspect they bite. Tarballs and source are not packages
in the sense we care about here. The key requirement is detailed
dependency information. All the interesting functionality of a package
management tool depends on this.

So I think the apt-pkg approach makes sense. No need to fool with CORBA
and so on. Just have library code to handle each of the small number of
cases we care about.
 
The fact that libapt-pkg already exists is a strong argument in favor too.
:-)

> (Hint: if anyone decides on trying to come up with a new package format,
> or something like what I have described, PLEASE PLEASE PLEASE make sure
> it can deal with sub-packaging!  This is one thing I truly --HATE--
> about RPM; either the functionality isn't there or nobody uses it.
> 
> I would really love to have the choice to not install some of the
> programs included in, e.g. gnome-games, if I decide that I really only
> want Freecell.  :)
> 

What you want to do here is have a Freecell package and a way to group
packages (e.g. the gnome-games group). Next generation dpkg will probably
have this.

IMO it makes no sense to have an install tool on a free Unix distribution. 
For .deb and .rpm packages, they will just be installed when you
double-click. At most, the install scripts could use 'dialog' to ask
questions instead of requiring text-mode interaction. An InstallShield
thing would be little more than a progress meter. (I guess that's all it
really is anyway.)

We simply have a better way to install software than broken operating
systems like Windows. It's a big UI innovation GNU/Linux should capitalize
on big time. There's no way proprietary software can have anything like
the integration and magic upgradability of Debian's 2000 hand-crafted
packages.

Havoc