Re: Packaging system effort

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Thu, Feb 26, 2004 at 10:58:34AM -0600, Matthew D. Fuller wrote:
> > It is highly desirable to be able to install multiple versions of
> > one program at the same time. Besides means to enable this in the
> > filesystem (symlinks, variable symlinks, VFS voodoo, etc) - which
> > might not be available on all target platforms - this also adds some
> > more questions concerning the logic of newly installed packages.
> > Imagine two perl versions installed: 5.6 and 5.8; which version
> > should the newly installed spamassassin depend upon?
> 
> VFS Voodoo(tm) is almost certainly the Right Answer to this, but it's
> a bear to implement (even with a good, clean layering system in the
> kernel to hook into, there's so many edge cases to consider).

Using VFS Voodoo may effect performance and memory usage of the kernel,
therefore it use should be reduced to the absolutely sensible minimum.
Choosing e.g. the perl version of an application can be done via customizing
the Perl script when the desired version was selected.

> > Debian's way of providing -dev packages which have been splitted off
> > is always a highly controversial point of discussion.
> 
> Hate.  Hate hate hate hate hate.  Big throbbing pots of hate.  Flaming
> hate.
> 
> I'm not overly fond of this concept, I s'pose.

I thought of using subpackages for this. E.g. you have a libfoo package,
which includes a libfoo-dev and libfoo-doc package. If the user doesn't
want them, she doesn't have to install them.

> If we do a VFS Voodoo(tm) solution where each package is installed in
> its own filesystem, we don't need to worry about atomicity   8-)

See above comment about speed and memory usage 

> > If possible, a nice addition would be the optional integration of
> > installation and build management of the base system.
> 
> This always makes me uncomfortable, even as I acknowledge that it's a
> necessary step at some point.  There's so much foot-shooting that can
> go on, and so much vein-popping.

I want to maintain the separation of base system and additional software,
but having a proper way for updating the base system is necessary. I don't
want to start a mess like Linux with everything installed under /usr.

> > It should be possible to build and install packages as an
> > unprivileged user.  Sometimes local security policy or laziness of
> > an admin demands the installation of a package into the user's home
> > dir. A nice point would be native support for such in the packaging
> > system. This doesn't mean that binary packages need to be
> > relocatable into home dirs, but the system would need to provide an
> > alternative (user home) location of package registry.
> 
> The system should be able to determine at least the install base
> ($PREFIX or some such) at install-time.  Of course, that gets
> increasingly icky in programs that internally hardcode paths at
> build-time.
> 
> What do you mean by "alternative package registry"?  Is that
> 'registry' a noun or a verb?

Well, the package management system has to keep track of the installed
packages for each user. One problem is deinstallation of a package from
root while a user package still depends on it.

> > The packaging system descriptions shouldn't consume too much space
> > in general and inodes in specific.
> 
> Are you referring to the build location (i.e., /usr/ports) or the
> database location (i.e., /var/db/pkg)?  Either way, it's definately
> true.

The build location is IMO not a big deal, but the database location is.
Having one file for each package there is IMO the optimal number.

> > The system should be able to bootstrap itself. This means it
> > shouldn't depend on the system tools be included with the host OS.
> 
> That means self-installing packages (sorta like self-extracting ZIP
> files).

No, it means having a makefile or shell script to build all the internal
tools, e.g. the package installation framework.

> > Basic Principe: The last instance of decision is always the user -
> > but she shouldn't have to be in most cases.
> 
> Amen.

Right :)

Joerg

> -- 
> Matthew Fuller     (MF4839)   |  fullermd@xxxxxxxxxxxxxxx
> Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
> 
> "The only reason I'm burning my candle at both ends, is because I
>       haven't figured out how to light the middle yet"