Hi Sam! On Sun, 23 Nov 2008 21:09:15 +0100, Sam Steingold wrote:
I am fine with one package with two linking sets, but having two separate packages is IMHO a better solution, since it will help people who wants a minimal clisp installation.
on a second thought, you might be right. in fact, you might want to offer several different packages, e.g., in addition to clisp-base, - clisp-db (base + bdb + postgresql) - clisp-gui (base + clx + gtk) - clisp-net (base + rawsock + ???) - clisp-math (base + libsvm + pari)
While this could be a good option, we should evaluate if it is worth in terms of package content and size.
you might also build clisp with dynamic modules and offer individual modules a la carte.
While my previous point is still valid, thank you for the hint: I have never considered before dynamic modules as an option.
Is there any disadvantage with two separate packages?
are clisp-base and clisp-full going to be independent? if yes, which will be used by default?
I suggest that clisp-full depends on clisp-base and the latter is _always_ the default (as it is with the normal clisp installation).
The situation will be as you have described, with the variant that I still need to think if keeping an extra/dummy clisp package is worth.
Note also that the file clisp/unix/INSTALL has a section "Additional Information for Maintainers of Binary Packages" with a "Module selection" subsection. I think it would be a good idea for debian to follow those suggestions.
I have already planned to better check that file, but for the next Debian version, i.e. the first one after lenny.
I am mostly concerned with "offering a uniform experience to all CLISP users regardless of platform or distribution".
I am also interested in "uniformity" and "consistency", thus please feel free to cc: me in any discussion on that argument. Thx, bye, Gismo / Luca