[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gnu packaging ideas

From: pancake
Subject: gnu packaging ideas
Date: Thu, 15 Jun 2006 16:10:14 +0200
User-agent: mutt-ng/devel-r782 (FreeBSD)

I was busy these days, so sorry for my late reply..

I was thinking about a way to implement the missing parts to stut to
get't fully functional like apt, but with some nice stuff enjoyable
for the Hurd :P

I've wrapped the stow api of stut to allow to choose between three 
different implementations:

(define stow-implementation "shell")

Available ones are:

        "fs" (stowfs = not yet implemented <- anybody?)
        "guile" (the scheme implementation of stow)
        "shell" (calling the /real/ stow)

Nowadays stut only handles pkgsrc binary package, but I think we must
think on a design for GNU.

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?

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:


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.

stut will fetch the .gnu-package file (a tarball), and configure't.

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


In metadata we could store install/deinstall scripts.

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

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

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

What do you think about?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]