[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnu packaging ideas
From: |
Alfred M. Szmidt |
Subject: |
Re: gnu packaging ideas |
Date: |
Thu, 15 Jun 2006 21:50:32 +0200 (CEST) |
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?
[...]
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.
A sexp is far easier to use and extend. That some people are lazy is
no excuse, they will have to learn many new things anyway. I think
that anyone can understand and write the following without learning a
`whole new thing' (and this is just of the top of my head):
(require (package 'blah (or (>= 2.0) (not 2.6) (not 2.7))))
(not to mention that it is trivial to write a parser for this)
I think that using a sexp (or xml) is the only way to go. If people
find the sexp hard to understand, the one can have a front-end.
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.
There is no reason to disallow such flexibility, we can choose our own
policies. I think a good policy is to simple only provide sane
defaults, so for example emacs without X will not be provided as a
package from us, but instead, emacs with GTK might be provided
instead. If someone then wants to provide emacs without X they can do
so.
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.
I prefer `one package for each project'. Having such splits is
annoying, since there is no logical place where you should stop, is it
at documentation? Development headers? I'd prefer a single `gcc'
package that includes everything that gcc includes, then if someone
wishes to provide a gcc-c package that only contains the C compiler,
they can always do so.
Lets keep things simple, and learn a bit from the OpenBSD people.
[...] then use shell scripts for pre/post install scripts
We shouldn't need any pre/post shell scripts.
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?
I think the GNU Build System is a better substitute. That way you
have no central place to worry about to fix things for you.
Cheers.