Re: GNU Package Management System

[Alfred M\. Szmidt]

You commented on a really really really old document, most of what is
written in there isn't valid anymore.

   I think that a "/stow/package-vers_N/"SUMMARY directory is better,
   independent of the number of files that we will need.

That is what will be used probobly.

   [...]
   > The following are non-interactive scripts.
   > ** +post-install
   > ** +pre-install
   > ** +post-deinstall
   > ** +pre-deinstall

   What that scripts will do? IMHO, We do not need most of them, but
   we can provides something that allows the use of that kind of
   scripts.

Those scripts won't exist.  Providing them would be hard, since the
package manager is a file-system, and having a file-system run the
commands in those script could cause quite funny things.

   > Information like this should not be stored in the package,
   > because it varies, and it depends on other things aside from the
   > package itself.
   >
   > So I would put this information somewhere else, perhaps under
   > /var.  It could be one large file describing the entire state of
   > package dependency satisfaction.

   IMO, the package dependencies list will come in a file on SUMMARY,
   stowfs will read it and, if there is no problem, the package will
   be 'linked' to /, if there are problems, it will return the list of
   dependencies that are no provided on something like
   /stow/NDEPENDENCIES, a list of non-provided dependencies that are
   required by any package with the name of the packages that require
   them.

The package will always be installed if you link it into /stow.

   > 1) Unpack the package (if it is already unpacked, skip to 2).
   > 2) Copied, or symlinked into /packages.

   They are the same step, user can extract the package directly on
   /stow, and the uses of symlinks is a bad idea by default. Symlinks
   could be used to test a package but not to install a package
   definitely.q

Why do you think that using symlinks is a bad idea by default?

   >  b) Run pre-install script.
   >  c) Merge package into the file-system, skipping any nodes that are
   >    related to stow, or the package format.
   >  d) Fix files according to what is described in `+manifest'.
   >  e) Run post-install script.

   You forget to describe how packages installed from source may be
   used on that case, I think that we can work with GNU Source
   Installer to it be the way to create packages from source and put
   the binaries on '/stow/package...' Better than ask people to
   install binaries on '/some/place', create the package
   infraestructure and create a symlink to /stow.


Not knowing what the GNU Source Installer does, I can't really comment
on that.  Installing packages from source is done using the classic
three commands:

configure && make && make install DESTDIR=/some/place

And then creating a symbolic link from /some/place to /stow.

   > * Deinstallation of packages
   > The following steps happen when one deinstalls a package:
   > [Should we store a backup of changed files?]

   IMO, only if user want's it, something like debian does, 'aptitude purge'
   remove the changed files, but 'aptitude remove' doesn't.


   > 2) Run pre-deinstall script.
   > 3) Unmerge the package
   > 4) Run post-deinstall script.
   > 5) To completely remove the package from the system, we just remove
   >   the node /stow/PKG-VER here, otherwise this will be a no-op.

   Okay, but what will happen if a person try to do 'mv
   /stow/package-vers_N /dev/null' without check dependencies or
   runs pre-deinstall and post-deinstall scripts?

Dependencies are not important, they are only used by a front end, and
the scripts won't be avaiable to begin with.

Most of the details are sketchy, but what generally should be done is
known.

Cheers.