Re: gnu packaging ideas

[Alfred M. Szmidt]

   Package descriptor:

   I would like to have a package descriptor in lisp-like form, just
   one file to store this information:

    - package name (the same as the file) f.ex "gcc.gnu-package"
    - package version
    - dependencies and version ranges supported for dependencies
    - binary repositories path
    - one line description
    - long description
    - sha1/md5 hash of the binary file
    - name/mail of the maintainer
    - ...
    - something more?

Sounds good, though the format of each sexp (specially the dependency
stuff) needs to be pondered about.  I think that much of this data can
be grabbed from the Free Software Directory.

   It would be good to allow to choose some "flags", but to fix the
   complexity of this we could pack different packages with suffixes
   like this:

   classpath.gnu-package
   classpath-x11.gnu-package

I think this should be an optional feature, compiling the same package
with different flags is alot of work.  I'd prefer that "our" packages
are always compiled with all the features that are provided.  This
will reduce our workload considerably, if then someone wishes to have
an Emacs without X, they can create a new package called
emacs--nox--21.4.tgz or similar.  What do you think?

   So, this package descriptors can be stored on a directory
   updateable with gnuarch/rsync/git.., so we could get different
   sources on the same repo.

   stut will browse this database and resolve the dependency tree. The
   binary tarballs would be fetched from the repostories referenced by
   the package descriptor. so we could define some base repositories
   like FTP's, etc.

I'm not sure if I understand this.  Shouldn't the package descriptor
be stored with the package?  Or is this some canonical file which
lists all packages availaible from a site?  Much like the Packages
that gets used by apt-get?

I'm not sure that I like having stut try and calculate its own
dependencies, the idea was to have a translator (or a feature in stow)
that would provide this information in a dynamic manner, so a front
end would just look at that info to figure out which dependencies are
missing; a user could also look at it by just looking at the file.

Though on the other hand, it it extremely useful to calculate the
dependencies before installing something.  In which case
stut/apt-get/... would still have to figure everything out anyway.

   So, it would be nice to pack some scheme scripts inside the
   package:

   [tarball]
   packagename-version/...
   metadata/...

Consider a user extracting several packages in the current directory.
The metadata/ directory will be overwritten.  A better scheme is to
store metadata in package-version/metadata.  I used
package-version/SUMMARY/ as the directory for containing meta-data in
one of my notes.

   In metadata we could store install/deinstall scripts.

A package must work without these.  Simply extracting the package to
/stow should be enough.

   stut allows us to switch between different versions of the same
   package, so a version-range dependency would be required.

Switching between versions should also work from the command line (by
using ln or similar).

   When a package is installed all installed files are registered and
   hashed. This is useful for security reasons.

I think while this is a good idea in practise, it might lead to a bit
of a mess.  Consider a user installing package A with stut, and then
installing package B in the `configure && make install' manner.
Package B will now not have any hashes, or be registered with stut.
If I understand correctly.

Any file that stut updates should be provided by a translator instead
of having stut update that file, this will allow users to use normal
file-system tools to play around.

   About how to build these binary packages ...I think GSC is the way,
   but GSC must allow to create this kind of binary packages.

Would be trivial to add, given a command to produce such packages.
Right now all GSC does is take the directory where the package was
installed an create a tarball of it.  See [gsc]/MK/targerts.mk:_package.

Happy hacking.