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