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