|
Re: how to handle: a package needs another package with a particular option: msg#00250os.netbsd.devel.pkgsrc.user
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. |
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| Previous by Date: | Re: Problem with pkg_rolling-replace: 00250, Petr Janda |
|---|---|
| Next by Date: | Re: how to handle: a package needs another package with a particular option: 00250, Steven M. Bellovin |
| Previous by Thread: | Re: how to handle: a package needs another package with a particular optioni: 00250, Steven M. Bellovin |
| Next by Thread: | Re: how to handle: a package needs another package with a particular option: 00250, Steven M. Bellovin |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |