Default variants
N_Ox
n.oxyde at gmail.com
Tue Aug 14 11:00:38 PDT 2007
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.
--
Anthony Ramine, the infamous MacPorts Trac slave.
nox at macports.org
More information about the macports-dev
mailing list