Re: Package format/management ramblingss

[Alfred M. Szmidt]

   Stow is small and reliant on Perl.  If the goal is to write our
   own, why not do it now?

Because if stow can be used with minor modifications, it will only be
a waste of time.  That it is reliant on Perl, is also completely
unrelated, Perl will be installed since many programs already depend
on Perl (Automake, Autoconf for example).

Stow is a small step into the direction of what the GNU system's
package management will look like.

   So the the tarballs now contain the binary "application" and the
   metadata?

To use or not to use tar balls is not decided, but in either case you
will need some format (be it tar, pax, or cpio), and this will contain
the binary package and meta-data.

   So we must re-create every tarball?

Only when the source for the package has been updated, or when changes
to the build Makefile have been made that would modify the built
package.

   Of course I really like what Jereon was saying today on #hurd about
   the pax format.

And that is?

   * pull the pax file which contains the package and the metadata
   (relationships, install paths for stow, pre/post scripts??)

pax cannot hold meta-data like pre/post scripts in its header from
what I know, only strings.

Also, if you store information like the description of a binary
package in the pax-ball, you will loose this when you extract it.  So
it is better to use a plain tree which contains all of this, and store
it with the extracted information.

   * the package gets dumped to packagefs which automagically creates
   the appropriate symlinks

First of all, packagefs is a bad name, it doesn't have anything to do
with packages.  Also it cannot handle the running of pre/post scripts,
since they might be interactive.  A suitable name is stowfs, since it
should only handle the merging of files into the system (and maybe
resolving dependencies).  Then we will have a program that will handle
the rest (running pre/post scripts for example).


Since Barry is quite eager here, I will outline a rough draft to what
I think the package manager should look like.  It is _very_ rough, so
if I forget anything, please note it.  And please comment about
anything that might be disliked.  Some of the steps outlined below
must be skipped for the time being, since we don't have stowfs yet
(specially the /stpw/PKG-VER/,availability node).  The names of all
the nodes are also subject to change.

One final note about the naming of nodes, all nodes that are related
to the binary package start with a '+'-sign (plus), nodes that are
provided by stowfs start with a ','-sign (comma).

Each package might have a "disabled" and "enabled" bit that can be set
(or unset), which will make the package available to the whole system.
`stowfs' would provide this bit (a file) which pkgadd and pkgrm would
twiddle, and then run pre/post scripts.

So to install a package one would do the following steps roughly
(this, and the disabling/removal of packages should of course have a
front-end utility so that these steps are transparent to the user):

[I assume that if a error occurs during the adding or removal of a
 package into the system, then the program will clean up gracefully
 after it self and restore the system to its previous state]

,----
| 1) Unpack binary package.
| 
| 2) Insert it into the stowfs file system.
| 
| 3) Run `pkgadd'
| 
|   3a) Check that dependencies are full filed, if not resolve them
|       (by installing any packages that this package depends on).
| 
|   3b) Run pre-install script.
|
|   3c) Do what is listed in /stow/PKG-VER/+manifest (see below what
|       it contains).
|
|   3d) Enable package using a node that is made available by stowfs,
|       say /stow/PKG-VER/,availability.
| 
|   3e) Run post-install script.
`----


To uninstall, one would have the choice of "removing the package
completely" and "disabling" the package.

The disabling of a package:

,----
| 1) Check that no dependencies break if we disable this package, if
|    not resolve this (by disabling packages that depend on this
|    package)
| 
| 2) Run pre-uninstall script.
| 
| 3) Disable package in stowfs.
| 
| 4) Run post-uninstall 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.
`----

To check dependencies, stowfs would resolve them, and list any missing
ones in /stow/PKG-VER/,dependencies (in format that can be read and
parsed easily).  For now, this will be handled by a function in
pkgadd/pkgrm, so that node will not exist (or just be empty).  But it
will be easy to modify this when stowfs comes into existence.

For running the pre/post scripts, pkgadd/pkgrm will run
/stow/PKG-VER/+{pre,post}-{un}install as needed.

The following nodes should also be provided by the binary package:

/stow/PKG-VER/+description -- the description of the package.

/stow/PKG-VER/+md5sum -- list of all md5sums in the package.

/stow/PKG-VER/+md5sum.sig -- a signed version of +md5sum using gpg.

/stow/PKG-VER/+manifest -- a list of files that are "special"
                           (permissions, if they are configuration
                           file--this is needed so that when a upgrade
                           comes the user can inspect if she wants to
                           modify her configuration file, etc)

/stow/PKG-VER/+arch -- the architecture the package is intended (was
                       compiled) for (all, i386, i486, sparc64 ...);
                       this is checked during the dependency check.

                       We should figure out if it should be possible
                       to install the same package but for different
                       arches onto the same system.  I think that this
                       would be a nice feature, but I am unsure if it
                       would be useful.


This is what I think our package manager system should look like,
please comment about anything you like/dislike/etc.


As a small final note, I might add that the *BSD package format is
somewhat similar to what I have outlined above.  I will send the
manual pages for the utilities that are used to create, add, remove
and list information about packages in *BSD (to be exact, OpenBSD) in
a separate mail to this list so that everyone can look at that.

Happy hacking!