[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Improving GNU PM translator
From: |
Alfred M. Szmidt |
Subject: |
Re: Improving GNU PM translator |
Date: |
Mon, 27 Sep 2004 10:03:04 +0200 |
What do you mean with "GSC creates packages" ?
Do the
./configure && make install DESTDIR=/package/foo
procedure ?
Yes, and store some meta-data like dependency listsings. So that the
package manager can check that it needs foo and bar to work. The idea
is just that the GSC should build all the bits of the GNU system so
one can automatye as much as possible.
I don't understand differences between packages and tarballs,
A package, a proper package that is, has a bit more information then a
"plain tarball". But they are both essentially the same.
GNU PM translator, will involve / and we can set it to act on /bin
/sbin /usr/bin or whatever else directory we want. Translator I am
talking about, is a translator for /packages itself.
Hmm... I don't follow here. What is your purposed difference between
this translator on / and the translator on /packages?
My idea (and I think Marco's) was to have a translator sit on /, and
you would supply a list of directories that it would search. So
setting things up would be done with something like:
settrans / /hurd/packagefs --search=/bin:/sbin:/lib /packages
and then the directories listed in --search would be under the control
of packagefs and it could do whatever it wants with them. And
/packages (the last argument) would be where you create the symlinks
etc.
I simply explain my point of view:
my translator is a layer between user and /packages. Layer means
(correct me if I am wrong again) that read and write operations may
be filtered by the translator.
Correct.
Translator job consists in:
- installing a package as you try to make a subdirectory
or a symlink in /packages
This must modify /bin, /lib, etc somehow. This is why I do not follow
your suggestions above ("a translator for /packages itself").
- showing real package directories (instead symlinks) when someone
reads /packages
Well, the thing is that we can make the "symlinks" in /packages and
make them show up as anything we want. It is just a matter of
modifying a function call for the translator.
I think that they should show up as symlinks, that way one can see
from where the package is pulled infrom (/packages/emacs ->
/foo/bar/emacs), or if it was copied into the /packages directory
directly.
Cheers.