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

On Mon, 18 Dec 2006 08:29:37 -0500
Greg Troxel <gdt@xxxxxxxxxx> wrote:

>   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.
> 
Hmm...  I'll have to think about that one.  I'll note that claws-mail
already has a fair number of different features that are only
selectable at compile time.


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