Re: how to handle: a package needs another package with a particular option

"Steven M. Bellovin" <smb@xxxxxxxxxxxxxxx> writes:

> I'm trying to put together a package for the S/MIME plug-in for
> Claws-mail (currently sylpheed-claws in pkgsrc; I'll take care of that
> renaming as soon as the current freeze is over).

As much as I like to avoid renaming, it seems that we really should
when the upstream package has a new name.  The rename is a good
opportunity to see if claws-mail should be split into multiple packages.

> The problem is that the plug-in requires gpgsm, which is installed
> as part of gnupg2 -- but only if the 'gpgsm' option is defined for
> it.  How do I handle that?  (There are comments in the latter's
> Makefile indicating that perhaps its modularization is wrong, but
> I'm not going to tackle that, especially since smime-plugin needs
> another piece of gnupg2 as well.)

The right thing is, as you point out, to fix the gnupg2 package.
I don't think we have any way of enforcing dependencies on options.

In general, I'd say a package has no business setting options for
other packages.

One thing to do depend on gnupg2 and then look for gpgsm at configure
time and fail.

We could also make gpgsm a suggested option, making it more likely to
be present unless someone has chosen not to install it.  Using it
pulls in dirmngr, which is "only" 400K installed, and gpgsm itself
isn't that big, especially compared to all the stuff gnupg2 already
depends on.  Perhaps John has some insight into why the default is set
as it is.