Re: a proposal for the packaging system

[Chris Pressey <cpressey@xxxxxxxxxxxxxxx>]

On Tue, 1 Jun 2004 09:06:18 +0000 (UTC)
Raphael Marmier <raphael@xxxxxxxxxxx> wrote:

> [...]
> If we want to get things a bit clearer, we must deconstruct the
> problem.

Very much agreed.  A packaging system is a massive undertaking and if we
don't "divide and conquer" it will take forever.

> [...]
> For every improvement proposed, it has to be shown what level would be
> affected and the consequences weighted on cost/benefit. Maybe someone
> should start a wiki on the subject and people would submit their
> proposal they already exposed in the list in this formalised way.
> Then, it'll be easier to take decisions.

By happy coincidence, GeekGod of www.livebsd.com fame has begun by
wiki-fying Simon's wish-list.  It still needs to be broken down and
categorized, but since it's a wiki, presumably anyone motivated could
start on that:

  http://www.livebsd.com/cgi-bin/trac.cgi/wiki/dflypkg

> [...]
> In the meantime, I reread Matt's memo on packaging and obviously the
> bitterest grief with current solutions is the inability to do
> something like install an new version of libncurse with some funny
> option without breaking the application that relie on a "normal"
> install of it. Now, that would be some _innovation_, and that would
> definitely differenciate DBSD from any other unix.

Yes - the thing is that this innovation isn't inherently package
related, as you've mentioned, although of course it makes sense for a
package system to exploit it.  Once the "filesystem views" are in place,
pretty much any package system could be written or adapted to use them.

> [...]
> Filesystem Overlay for DragonflyBSD:

OK, I won't pretend to have digested this in its entirety yet :)  But it
definately sounds like its on the right track...

In really simple terms: each piece of software has a version.  However,
each piece of software generally does not expose that version to the
system's namespace (the file system.)  So you have, say, autoconf 2.13
and autoconf 2.57.  Some other pieces of software may require one and
not work with the other - but these pieces of software refer to both as
simply 'autoconf'.  Therein is the collision.  It becomes slightly more
complex with shared libraries and all, but as I understand it, that's
still the basic problem.

We don't need VFS Voodoo or filesystem overlays to resolve these
collisions.  We can do it with varsyms, or clever use of plain ol'
symlinks.  But VFS Voodoo would certainly be the cleanest way to address
it, if done correctly (and I have few doubts that we'll do it correctly,
if we do it at all, which we will :)

Anyway - IMHO sorting this all out comes before the packaging system. 
However, the first release will in all likelihood come before this too. 
So, IMHO, right now we should be concentrating on making DFly as stable
as can possibly be.  As they say, you only get one chance to make a
first impression; let's make it a good one!

-Chris