Re: gnu packaging ideas

[Alfred M. Szmidt]

   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.