Re: Apache should never be a mandatory dependency

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Sun, May 18, 2014 at 08:52:13AM +0100, Jonathan Perkin wrote:
> * On 2014-05-18 at 05:06 BST, Alistair Crooks wrote:
> 
> > 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.
> > 
> > Anyway, to get back to the worked example - this will make sure a
> > webserver is installed.  It can take preferences from a setting in
> > /etc/mk.conf (on a per-platform basis), of the form
> > 
> >     GENERIC.webserver=      apache22
> > 
> > If no preference is given at package installation time, it will select
> > the default one for you.
> > 
> > So the line in the webserver pkgsrc entry Makefile would look like:
> > 
> >     .include "../../mk/bsd.prefs.mk"
> > 
> >     .if defined(GENERIC.webserver)
> >     _WEBSERVER=${GENERIC.webserver}
> >     .else
> >     _WEBSERVER=${_DEFAULT_GENERIC_WEBSERVER}
> >     .endif
> > 
> >     DEPENDS+=       
> > {bozohttpd>=20140201,apache22>=2.2.27,apache24>=2.4.9,nginx>=1.6.0}:../../www/${DEFAULT_GENERIC_WEBSERVER}
> > 
> > Seems simple to me, and, in lieu of any other mechanism within pkgsrc,
> > should work. I'm less chuffed with the version numbers there, but I
> > wonder if there's some way to generalise them.
> 
> We use this type of mechanism at Joyent to support all the various
> MySQL forks we've added.  It's ... not great.
> 
> Users regularly get confused because some random package happens to
> need to pull in a MySQL client library, and due to the DEPENDS
> matching will pull in the first match, which is often not what they
> want to use.  When they come later to install their preferred MySQL
> server, they can't due to conflicts, and have to unwind the
> installation back so that they start with their preferred version.
> 
> This is somewhat unavoidable due to hard dependencies on
> libmysqlclient, which changes version between forks, so currently is a
> necessity we have to put up with (and we produce specific images to
> make it easier for users to pick their preferred option).
> 
> When the dependency is soft, like with a web server, then I would
> definitely not want any of this getting in the way.  If people really
> want it regardless, that's fine, but please can we have a global knob
> to turn it off completely to save us having more diffs.
> 
> We're working to remove dependencies to make packages more flexible,
> rather than the other way around.

[Previous message left for context, as I've left this far too long to
reply to - agc]

Thanks for the insight - I can see that this would be a problem with
a real package with a library in it, but for indirecting through a
meta-package, I'm not sure the case is quite so similar.

And so onto plan B.

Second suggestion, then, is to create some form of lightweight
package for the indirection, like, say, a site-specific symbolic
link which can be made (again through a mk.conf setting), and the
"make package" command. e.g.

in /etc/mk.conf

        # strict version numbers would be a lose here
        PKG_GENERIC.webserver= apache

and use the "webserver" keyword in nginx, apache, bozohttpd, lighthttpd,
et al pkgsrc Makefiles:

        PKG_GENERIC.category= webserver

which would create a webserver-0.0.tgz binary package when the
desired binary package was built.

Yes, I know this is subclassing the existing categories, but it seems
useful to me to have such a mechanism.  Depending on a generic and
abstract webserver-0.0 package would trigger the build mechanism
(by checking whther PKG_GENERIC.${PKG_GENERIC.category} was defined).

It's possible to change the desired specific package by using a
different value in /etc/mk.conf.  Failure to flush out the old one
would have the same results.

Whatever way this is done, it needs another layer of indirection (with
a tip of the hat to Butler Lampson/David Wheeler).  I'm sure people
can improve on my rather handwavy explanations above.

Regards,
Alistair