On Wed, Jul 11, 2007, Ralf S. Engelschall wrote: > On Wed, Jul 11, 2007, Thomas Lotterer wrote: > > > The topic is about how to handle with_foo for a with_foo_bar option that > > only makes sense in concert with with_foo. > > > > > On Tue, Jul 10, 2007, Christoph Schug wrote: > > > > > > For me, it looks more like the second [implicit] case, but I might be > > > wrong. If not, there should be some fiddling in the "fixing implicit > > > extension dependencies and correlations" section, right? > > > > > I remember the "implicit dependency" issue but wasn't sure what the best > > practice is to make clear to the user that with_imap_annotate implies > > with_imap. My ideas were: > > > > - use "if with_foo || with_foo_bar" in the "with_foo" logic > > this will build with_foo if only with_foo_bar is given but > > "rpm -qi" will show up with_foo=no. Bad > > > > - implicitly set "with_foo=yes" when the user chooses "with_foo_bar" > > AFAIK the current practice. Build and query ok, but somewhat magic. > > > > - make the package require itself, enforcing an explicit setting > > Something like "if with_foo_bar then require self::with_foo=yes" > > > > If the latter works, I'd prefer it. Never tested it. > > As I think RPM will not allow the latter, just use the second one. > This is what we already have in a bunch of similar packages.
Okay, I just commited it the secondy way [1]. Anyway, another disadvantage of this method should be mentioned. When altering options implicitly this change is not reflected in the package description, i.e. doing an 'openpkg rpm -qi php' still shows 'with_foo=no' even if it was triggered to 'yes' by enabling 'with_foo_bar'. Well, another question regarding both PHP packages, 'php' and 'apache-php'. Why is there a run-time requirement for a MTA by default? I thought this is exactly why we have the 'with_sendmail' option. If no one speaks up, I will drop the default MTA dependency. [1] http://cvs.openpkg.org/chngview?cn=36183 -cs ______________________________________________________________________ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
