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

[Greg Troxel <gdt%ir.bbn.com@localhost>]

  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.

I recommend against making options for standard plug-ins.  They should
either always be there, or be additional packages.  Options are hard to
deal with, since bulk builds don't set them, and you create the same
problem you are encountering with gpgsm.

Options are appropriate for changing behavior in ways that can't be
separated, e.g. whether to linke with exiv2 in gimp-ufraw.

So I'd recommend that you do

claws-mail-base         base, with no plug-ins

claws-mail-foo          standard plug-in foo
claws-mail-bar

claws-mail              depends on base and all standard plugins

This way the user who installs claws-mail gets what the claws-mail
people say is standard, but the minimalist can pick and choose.
Importantly, one can later install claws-mail and just have it build
the extra parts.

Or, you can just make claws-mail and always include the plugins.
But, for the sake of pkg_rolling-replace users :-), I think it's good
to implement the final scheme first whenever possible.  Given the list
of standard plugins, I can see why you want to split the base and
plugins.