Re: Packaging system effort

["Matthew D. Fuller" <fullermd@xxxxxxxxxxxxxxx>]

On Thu, Feb 26, 2004 at 06:43:02PM +0100 I heard the voice of
Joerg Sonnenberger, and lo! it spake thus:
> 
> Using VFS Voodoo may effect performance and memory usage of the
> kernel, therefore it use should be reduced to the absolutely
> sensible minimum.

It certainly has that potential.  OTOH, it lets us do all kinds of
really neat things really "cheap", like:

- Uninstall, install on another box (complete with all special options
  and config files), backup, etc, just by copying or removing one file

- Build plists and do similar surveys of installed-size and number of
  files with nothing but ls

- Temporarily disable a package simply by turning off visibility
  through that filesystem

- Access specific versions of a required package just by a little
  magic request, even when all the filenames overlap, and with less
  contortions than using variant symlinks or something for it

- For non-overlapping versions, it's easy to build the "normal"
  /usr/pkg; it's just a union overlaying all the invidual pkgfs's
  mashed together.  You'll need some tools for configuring which
  packages go in that 'default' set and resolving conflicts, but
  you'll have to do that sort of thing anyway.


It's certainly very easy to implement in a way that explodes your
kernal address space before you even get as far as displaying a shell
prompt.  But I think with some creativity, it can be made to be not as
heavy weight as one might fear; and it certainly brings a lot of
advantages.


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

I like the idea of "package profiles", where you have some (preferably
a very few, and standarized) options for how to install it.  You COULD
perhaps collapse that with a mechanism for per-package options
(WITH_LIBFOO, WITH_BAR), but I think I'd prefer that to be somewhere
else.


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

Yeah.  There's some big advantages to packaging everything, if we can
just avoid the ickiness that comes with it too.  What's the point of
having your cake if you can't eat it, too?


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

Yah, I was just wondering which way it was meant.  Whether it's
"package registry"-the-noun, as in the place where you register what
packages are installed, or "package registry"-the-verb, as in
registering where the package is installed (that's not very clear,
either.  Stupid English.)


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

It's perhaps a lesser deal, but it would certainly be nice to collapse
it a bit.  My (FreeBSD) /usr/ports is using 140k inodes.  That's kinda
a lot.


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

I think a self-installing package (at least for the package management
tools) would rank high on the "niftiness" scale.  Then later on you
can upgrade it within the package management framework easily, and
still have the ability to install it without chicken/egg problems.



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