Re: Package format/management ramblingss

[Soeren D. Schulze]

Marco Gerards wrote:
> >     Yet another aspect is the handling of dependencies.  Therefore, every
> >     package could have its own dependency file, which is syntactically
> >     similar to the preferences file:
> >
> > This would all be processed in advance.  Recalculation would be needed
> > only when the set of installed packages changes.
> >
> > The Hurd lets a program ask to be notified whenever a certain file or
> > dir gets changed.  Using this feature the translator for /bin would
> > always know when to recalculate something.
> 
> Please forgive me if this has been discussed before, I just know what
> we have discussed at the LSM several years ago.  So I just continue
> here with what I can remember.  If something was already discussed,
> please ignore that part, I will try to catch up.  The main reason for
> me to write this email is to prevent confusion.
> 
> What you are talking about sounds like /bin would get a translator.
> And /sbin would get another, etc.  That is where is looks like Soeren
> got confused.

I admit I did not even think about these details...

But if /hurd gets yet another one, we would run into trouble.
Perhaps we should implement something like a ``kick-starter'' like
an initrd for the Hurd.  It sets the initial root and packagefs
translators, which are removed later and replaced with the preferred
translators.
But it is completely off-topic for now.
 
> AFAIK the idea is to have a translator set on "/", that is a union of
> all subdirectories in /package/*.  So /bin will be a union of
> /packages/emacs/bin, /packages/bash/bin, etc.

a translator on /?!
What about all those subdirectories /var, /home etc. that are not
controlled by the translator?

> Now that I am thinking about it, how should the translator be set?  On
> top of /?  Or would it be better to set it on top of something like
> /usr or /local?
> 
> The problem is that if we set the translator on top of "/", that
> translator should be unioned as well.  In that case the "/" filesystem
> should be the one written to.

Is this the problem I mentioned above?
Well, I think we should therefore redefine the purpose of /usr:
"everything controlled by the package manager, including the former
/bin and /sbin"
For compatibility reasons, these symlinks should be provided:

/bin -> /usr/bin
/sbin -> /usr/sbin
(/hurd -> /usr/hurd? -- see above)

and probably also

/share -> /usr/share
/include -> /usr/include
...

but not

/src -> /usr/src
/local -> /usr/local

because they are not controlled by the package manager.

Perhaps, access of the directories in / should be the recommended way
because implementation might change.


Soeren Schulze