On 6/15/06, pancake <address@hidden> wrote:
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:
I think "lisp-like" syntax should be avoided. Remember that this is all just a method for developers to package their softare, or for software to be packaged for them. You need to remember that lisp syntax is inredibly foreign to the majority of devlopers - why force them to learn a whole new thing just to package software?
- package name (the same as the file) f.ex "gcc.gnu-package"
- package version
I think you probably meant this, but I think we also need to inlude the softwares version. Most package managers use the softwares version, then have a package revision number relating to how many times that particular version has been packaged.
- dependencies and version ranges supported for dependencies
I think that complex dependency relationships are a must. That is, I don't think this should be a simple: "requires blah >= 2.0" more "requires blah >= 2.0 not 2.6 not 2.7", etc.
- 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:
classpath.gnu-package
classpath-x11.gnu-package
This is silly and impractical, and leads to a large number of hard-to-maintain and almost reduandant meta files and packages. There are many packages that offer a lot of customization - how'd you like to be the maintainer that has to maintain 20 different versions of your application? Think of something like PHP - that can have everything from 0 to around 100 dependencies, depending on your features.
The best way, using this model, is to try to build core packages that are a modular as possible, then offer extension packages. A good example of this is "gcc-core', "gcc-objc", "gcc-c++", etc.
The west way in general of doing this is to use flags and source packages.
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:
[tarball]
packagename-version/...
metadata/...
Why? We already have the .gnu-package file full of metadata, which told us where to fetch the package from. I can understand having install scripts in the package, but thats it. Maybe just a copy of the .gnu-package file for single distribution?
What are the point of the "scheme scripts" you mention? I can't see any advantage to using scheme as a syntax in packages - like I said, thats forcing typical package developers to learn an extremely foreign language just to package their software. Most package managers use their own format for files/scripts relating to the package manager, then use shell scripts for pre/post install scripts
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?
--pancake
Has anyone considered also offerin a source-based solution, like the popular Ports system in BSD distributions, or in Gentoo GNU/Linux's emerge program?
Mike Heath