Alistair Crooks <agc%pkgsrc.org@localhost> writes: >> [packages dpeending on web servers] > Aren't we getting into ALTERNATIVES territory here? > > What I would suggest is a "generic" style of package, let's call it > > pkgsrc/metapackages/webserver > > It's not just webservers this can be used for - I can think of editors > (and, within editors, sub classes of vi, emacs and other packages), > browsers, versions of scheme, common lisp, shells, etc. I think the key point is how to enable as much as we can with unmodified binary packages (no options). Within that, I suspect there are several flavors of dependecies. One situation seems pretty common, where a package does not actually depend at build time on a web server, but needs some web server to run. For those, it seems best to not have a dependency. If that's not going to be obvious, it can be put in DESCR. The other situation, where one really needs one of a class of things, and can't actually build/install a package without one of them, needs explicit support. For the first situation, resolved by just omitting the dependency, one can also think of inverting the dependency tree, so rather than have foo depend on apache (when really it's just that sensible use of foo needs some web server), foo could have no web server dependency, and then have packages foo-apache, foo-nginx, foo-thttpd, etc. The problem is not conceptual so much as it's annoying to have -- in the source tree -- many metapackages with no real content. A possible solution would be to have a more compact representation where these packages could be enumerated, essentially a metapackage generation language. Then, full binary builds would have them. I'm not sure this is worth it, but thought it was worth mentioning.
Attachment:
pgp7eldY1bmgw.pgp
Description: PGP signature