Re: Comparing PackageFS and GNU PM

[Luca Ferroni]

Il Fri, 24 Sep 2004 04:06:57 +0200,  "Alfred M. Szmidt" <address@hidden> ha 
scritto:

> Welcome, hope you enjoy your stay and I hope that it will be a long
> stay.
>

I hope too, thanks :)
 
>    1) PackageFS relies on existing package managers... currently they
>       work quite well, and maybe it would be better to improve them
>       than building a new one from scratch.
> 
> Could you explain how PackageFS (ab)uses the existsing package
> managers?
> 

PackageFS does not care about package managers job.
It just .... uses them :)
Before continuing with my explanation I reiterate that in PackageFS,
unlike in GNU, symbolic links contained in /packages are
and "end point". They come _after_ system real hierarchy,
do not change it in any way.

I'm trying to explain the situation through APT example 
(which is the only pm currently supported):

Debian provides libapt-pkg to deal with package cache.
At mount time, cache is read.
If an administrator make a package directory into INSTALL/,
PackageFS checks package availability in the cache,
if it is available, it calls "apt-get install -qq pkg"
(-qq is ok since all checks needed  are performed before through libapt-pkg)
then /var/lib/dpkg/info/pkg.list and pkg.conffile are opened, and
symlinks to real files are created in pkg subdirectory
At the end PackageFS gets dependencies and reverse dependencies 
through libapt again and creates specific entries.

APT problem resides in configuration files. There is no place where they
are specified, preinst or postinst manage them. I don't find a way to
support them in PackageFS.... do you?

> If it uses a existsing package manager, say dpkg, then it must store
> meta-data in /var/lib/dpkg/info/.  How is this handled?

No matter about this, it is pm job.

> How are packages presented to the file-system? For example, if you
> want to start emacs, how would you start it?

/usr/bin/emacs, no change done to system

> How do you make a package "available" in PackageFS?

At mount time, as cache is read, I get info about packages names and states
and I build the tree.

> What do you mean with "no many changes should be made in order to make
> it working on Debian GNU/Hurd"?  From what I understand, GNU/Linux
> userspace filesystem modules are _very_ different from the way you
> write translators in GNU/Hurd.  Not that I ever looked at how
> GNU/Linux does this.

Nor I ever looked at how GNU/Hurd translators are written :)
I thought a translator reinterprets system call and my implementation
currently does this.
If so, I think it would be easy to port PackageFS to Debian GNU/Hurd 
because it uses APT and you have same libapt-pkg as GNU/Linux.

> This I am a bit confused over, how do packages get into AVAILABLE/
> first of all?  They must get there, somehow, so this would be the
> first step in installing a package in PackageFS.  In the end, you have
> the same number of install steps.

No. PackageFS get them there. Users simply drag from AVAILABLE and
drop into INSTALL. Too much easy I think :)

>    1) Support to multi-administration: a new idea to give
>       administration capabilities to some users on specific
>       packages. I think this feature could fit to GNU PM too;
> 
> Could you explain this idea in a bit more detail?

Maybe a CUSTOM directory will be added.
Only root can write into this directory and he does, i.e.,
ln -s INSTALL/emacs CUSTOM/emacs
chgrp emacsadm CUSTOM/emacs
chmod g+rwx CUSTOM/emacs

Then if you want give administration rights on emacs to someuser, 
you simply add someuser to emacsadm group.
If someuser accesses files into INSTALL/emacs through CUSTOM/emacs,
he could gain root rights only on this package to manage its 
installation, removal, or to modify its owned files.

Just a vision ...

>    2) Exporting the file system to provide easy cluster management.
> 
> Shouldn't be hard, just setup a package translator on
> /package-cluster, where /package-cluster is exported via a NFS or some
> such.

I said that GNU PM is great :)

> What are your concerns about ordinary users?  They would have GUI
> front-ends with all kind of bells and whistles that they could use.
> 

What about if the GUI is an ordinary file manager ? I am not an "ordinary user"
and using packagefs and I feel easier to browse a directory 
than launch a specific application and deal with it through its interface. 
This is not a big matter though.

> I'm not sure I follow on "new PM from scratch", do you mean a program
> that handles resolving dependencies, "injecting" a package into the
> file-system, etc?
> 
> Then, yes.  Since the only way to achive what we want would be to do
> extensive changes to a already existing package manager that would do
> things the Hurdish way.  Like how would it make /bin list all
> installed programs (/package/*/bin)?  Just this is a very invasive
> change.

Yes, this would be great, all things you and other members say are great.
GNU System Creator, tarballs as packages archives and so on.
I was wondering if it was necessary to translate /packages/*/bin.
No doubt it is a very interesting idea, but how does it improve GNU?
Is it really necessary now? I am just asking...
Anyway it is a wonderful hack and I will be honoured if I can help you
in realizing such a new package management system.

> /packages-by-category/editors/emacs -> /package/emacs
> /packages-by-category/editors/emacs21 -> /package/emacs21

Ok. I should examine translators development in depth, they seem
interesting.

> The thing is that there is no code for it, or even a name settled.  I
> think that just refering to it as "the GNU package manager" would be
> OK, and maybe noting somewhere that it is a work in progress.  Maybe
> "the GNU pckage manager translator" would be better since it clarifies
> that it is a translator.
> 
> Really, I have no idea since no code has been written so a project
> name hasn't been decided!
>  

Thank you.
Luca

-- 
Luca Ferroni
www.cs.unibo.it/~fferroni/