Packaging (was Re: Annoucning DragonFly BSD!)

[Matthew D. Fuller]

On Fri, Jul 18, 2003 at 09:01:59PM -0700 I heard the voice of
Matthew Dillon, and lo! it spake thus:
> 
>     I don't consider such schemes as solving the correct problem.  The 
>     *real* problem with multiple package installation are all the third
>     party libraries packages depend on.  I do not want to duplicate 30
>     third party libraries 30 times for 30 interdependant packages, so 
>     there needs to be a way to share compatible third party libraries.
> 
>     The way I want to do that is by explicit versioning which is entirely
>     OUTSIDE the package's control, which I would accomplish by creating
>     an environmental overlay for the package which makes the exact 
>     versions of the libraries it is supposed to be using available to it
>     and hides everything else from it.

I think we're talking about orthagonal solutions here.

The former (in most post) concerns how packages are packaged, installed,
made available, deleted, etc.  The latter (in yours) concerns more WHEN
packages are made available to upper levels.  Perhaps we're conflating
means and ends?

If we have /usr/packages/libfoobar-1.2 and /usr/packages/libfoobar-1.3,
and both contain a "libfoobar.so.1", then the 'default' policy may well
be that /usr/local/lib/libfoobar.so.1 ends up filtering down through VFS
layering to the libfoobar.so.1 inside the -1.3 "package" (vnode,
whatever).  However, /usr/packages/bazquux-5.3 has a "jimmybob" binary
which for whatever reason requires the libfoobar from -1.2, not -1.3,
though the actual .so version is the same.  You'd then somehow register
that either "jimmybob" or "anything in bazquux-5.3" should filter through
to libfoobar-1.2 rather than hit libfoobar-1.3.

So, you'd have a direct mapping somehow in each package for what other
packages should be exposed in the namespace of that process (or perhaps
only in the initial namespace for loading?  I see problems either way
with that, actually.  Ugh.)  Failing having such a mapping, you'd have an
internal table of all the "libfoobar.so.1"'s and "jimmybob"'s and
"asdf"'s and "abc123"'s provided by all installed packages, and the
package with the 'greater' name (however, 'greater' is determined) wins
in this case of a file or part of package that doesn't explicitly set
what other packages are visible.



You all can keep talking about kernel messaging; that's over my head far
enough that I don't care   :P  But this packaging stuff, now; that's the
sort of thing that can really impact the User Experience (tm) in a great
way, and I think is one of the most visible things that could be done
beautifully here.


-- 
Matthew Fuller     (MF4839)   |  fullermd at 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"