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. _______________________________________________ gnu-system-discuss mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-system-discuss
