gnu-system-discuss
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]