N_Ox wrote: > > Le 14 août 07 à 19:58, N_Ox a écrit : > >> >> Le 12 août 07 à 05:28, N_Ox a écrit : >> >>> From what I've understood, the problem with default variants is that >>> if we do something like `port foo -bar` and that foo has >>> `default_variants +bar`, if an upgrade of foo is released, then `port >>> upgrade foo` will enable bar variant because variant disabling are >>> not saved and `default_variants +bar` will be evaluated. >>> >>> Is this really a problem? >>> Can't we use the magic of the TCL interpreter and ignore the call to >>> default_variants procedure in upgrade variant? >>> >>> These were my $0.02 for tonight... >>> ...I'll now take my pills and go to bed :p >>> >> >> Another problem with default_variants are variant conflicts. >> Something among those lines: >> >> variant apache2 {...} >> variant apache conflicts apache2 {...} >> default_variants +apache2 >> >> and this port command: >> port install +apache >> >> would produce an error because that would select apache and apache2. >> >> So here is my idea: let's create a new block named variant_group, or >> variant_choice, or even both. >> >> variant_(group|choice) webserver { >> variant apache2 {...} >> variant apache {...} >> } >> >> variant_group would tell us that we _can_ enable support for _one_ >> webserver, namely apache or apache2. >> variant_choice would tell us that we _must_ enable support for _one_ >> webserver, namely apache or apache2. >> >> That's all for today. >> Regards, >> > > Almost all... > I've forgotten something: > > default_variants +apache2 and port install +apache would not fail and > would automagically select apache instead of +apache2.
No one commented on this yet, so I will do start the discussion. I think this is a very reasonable idea to group variants to make it easier to implement choices. I also remember that we have some port having a choice between gnutls and openssl, so this is really a common use case. But there is still the need to record disabled default variants in order for this to work. Rainer _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev