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

On Mon, 18 Dec 2006 07:35:21 -0500
Greg Troxel <gdt@xxxxxxxxxx> wrote:

> "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.

My current plan is to have a package for the base system, with the
"standard plug-ins" -- its phase -- as options, and other plug-ins as
separate 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.

That's a good idea.
> 
> 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.
> 
This is for the S/MIME plug-in, which I'm making a separate
package, rather than the base claws-mail.  I was *not* happy when I saw
how much cruft it dragged in...



                --Steve Bellovin, http://www.cs.columbia.edu/~smb