Re: Comparing PackageFS and GNU PM

[Alfred M. Szmidt]

   I'm new to gnu-system-discuss, but I have read many messages
   belonging to GNU package management plan.

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

   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?

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

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

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

   3) PackageFS is transparent to (virtually) all GNU/Linux
      distribution, but this is not a GNU PM issue. However PackageFS
      could be transparent to any GNU distribution (I think currently
      no many changes should be made in order to make it working on
      Debian GNU/Hurd)

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.

[I would call it "GNU/Hurd distribution", there is only one GNU
 system.]

   6) In PackageFS, installation is accomplished through _only_one_
      operation (it may be cp, mkdir or drag&drop). In GNU PM you
      firstly need to extract package and then to create symlink. This
      is an important point to be evaluated if you want to provide
      usability to all users.

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.

   7) In GNU PM you can set the translator to get installed packages
      even from ~/packages, so any user has its own system. ...but you
      should have an active translator for each user I think.

That would be what would happen, if I set a translator on ~/packages
then this translator will be my own active translator.  They are
programs in the end, so if you start the program for each user, then
each user will have its own translator running.

   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?

   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.

   But what about an ordinary user? We should evaluate how it improves
   ordinary package management features.

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

   Do we really need to develop such a new PM from scratch ?

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.

What about the package format, this is very tied into the package
manager.  We want to have plain tarballs that one can use.  So that
something like,

./configure && make install DESTDIR=/package/foo
ln -s /packages/foo /package/foo

is possible to install a package.  The only real reason to have
meta-data like dependencies is so that it makes the life easier to
users would don't wish to compile from source.

And then, there is the issue of building the packages.  Debian depends
on each package manager to upload a package, this would be impossible
to achive for us.  Either you would have to find a person for each or
several packages in the GNU project to handle such uploads, or hope
that the maintainer does this.  Funny enough, it is very simple to
handle this in a central manner instead of a distributed one.  And
takes far less man power; a issue that we must take into account.
This is what the GNU System Creator intends to achive where even one
single person can manage all the packages that the GNU system is made
out of.

In the end, it is far easier to just to it from scratch.

   In PackageFS you can set mount options to view packages as a mere
   list or by categories or priorities. I think categories and
   priorities should be supported by GNU PM too. It may be useful to
   split packages in those sets, since we have a lots of packages on
   one system.

One could just write another translator, that would shows things in a
different view; and just send of control to the package manager when
one does something.

For example:

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

If you remove /packages-by-category/editors/emacs21 then the
packages-by-category translator would also remove /package/emacs21,
and in the end removing the package from the system.

And since we can notify about changes, removing /package/emacs21 could
make the packages-by-category translator aware that /package/emacs21
got removed, and so it would remove
/packages-by-category/editors/emacs21.

   I don't understand if translator affects the directory /packages
   itself.

What do you mean?  A translator is just a layer on the directory/file,
if you remove the translator you would get back your old
directory/file.

Say you have the file, /foo/bar to which you attach the Hello World
translator (a file translator that when read, will always show "Hello
World!") to /foo.  If you read /foo (it is a file now!) you would get
"Hello World!".  Remove the translator, and you have your old
directory back, with the file bar in it.

   I want to present GNU PM among related works in my thesis: how
   should I refer to it ? Is GNU Package Manager right ?

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!
 
   Sorry for message length.

It was enjoyable. :-)


Happy hacking!