Re: gnu packaging ideas

[pancake]

Sorry (again) for the lag O:)

On Thu, Jun 15, 2006 at 05:11:56PM +0200, Alfred M. Szmidt wrote:
>    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.

Yup, having an easy to grab all this info will make a database easy
to be generated. We must discuss about the format itself. SEXPs, Double dot
separated values, etc.. any proposal? idea?

>    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?

I think that there'r some features that must force the package to be
splitted in two. Like the X support that carries a lot of dependencies. BTW
lightweight dependency options must be enabled. BTW this is a package-specific
stuff.

>    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?

Yup this will allows us to install binary packages with no external database
required. Or use the package databases to get the pacakge info.

> 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.

Uhm, this looks really nice to me, but too complex, but it will be
faster and easily portable, because dependency tree could be done
by virtual symbolic links handled by the translator.

> 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.

The metadata directory does not have to be extracted to the prefix
directory, it must be handled by the package manager, so metadata directory
can be replaced by the .gnu-package descriptor file.

>    In metadata we could store install/deinstall scripts.
> 
> A package must work without these.  Simply extracting the package to
> /stow should be enough.

I think having pre/post install scripts would be pretty nice.

>    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).

that's handled by stut, it drops all ln's of the old version and creates
new ln's for the new version.

>    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.

Yep. BTW stut handles manually installed packages. But stut will not be
able to know some metadata. But it can be autogenerated or just handled
in some way.

This sound good for me.

> 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.

stut just acts as a frontend for this, (for portability, etc), so,
before writting the translator we could use this.

>    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.

Yup. Looks pretty nice to me these ideas. So mixing simple fs operations
with package system will make the software managing transparent for the
applications and users.

--pancake