Re: shared "system" libraries

[Sam Mason]

On Mon, Dec 12, 2005 at 01:48:45AM +0100, Marcus Brinkmann wrote:
> This means that reference counting is now not done at the "map copy"
> level of individual files, but at the "package-version" level of
> process filesystem namespaces.  Because process filesystem namespaces
> are potentially dynamic and more or less an abstract concept anyway, I
> think we have now moved far into the area where what actually should
> happen is defined by policies and contracts rather than technical
> features.

I think I must be missing something because this just seems to have
compounded the problem.  Originally the problem was when to reclaim the
space occupied by the (relativly) small set of files that the activly
running processes have open, now it's been expanded to whole packages.

That being said, I think the idea is great and is the right way to go.
It tidies up a lot of the package management mess that we have at the
moment e.g. you could install a package, perform any tests you want to
and if it isn't right you can remove the package without anything else
being affected.  With the current system upgrading something like libc
has the potential to break lots of stuff in ways that are very difficult
to recover from.

Your previous mail seemed to suggest that each package would be
installed in some big filesystem somewhere and (I'm guessing here) the
login process would be responsible for creating the initial unionfs and
passing that as the root filesystem that's going to be used by all
processes inside that login.  Not sure if that's described verbosely
enough.

The problem the package management has is then is that it needs to track
live references to open packages.  But the system already knows which
files are open and which filesystems are mounted, why not use this
existing code to do the package management's work?  A package file could
be a little filesystem, and the the login process would just mount the
required packages, union them together and give them to the first process.
The package management program would be free to delete any package file
and it would only really get deleted when the last process that used it
was killed.

I'm not sure if that's helpful, it just feels cleaner to me if packages
stay as little self contained blobs, rather than being extracted out
into a parent file system.  I'm not sure how much of a visible
difference it would make to users of the system, but I think that it
would simplify the package management code significantly if it could
rely on the garbage collection being done, cleanly and completly, by
the parent filesystem.


  Sam