tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Apache should never be a mandatory dependency

Alistair Crooks <> 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

Home | Main Index | Thread Index | Old Index