Re: Default variants
Le 07-08-16 à 09:37, N_Ox a écrit :
Le 16 août 07 à 15:19, Yves de Champlain a écrit :
Le 07-08-16 à 08:49, N_Ox a écrit :
Le 16 août 07 à 13:47, Rainer Müller a écrit :
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
As I've said in the very first mail of this discussion, I don't
think recording disabled default variants is really a problem.
The only case it is one is during upgrade, and what I've said
should fix that.
It should also be noted that
port install foo -bar
will fail as -bar is not a recognized option.
yves
I've never had problem with that.
And you can always type `port install -- -foo`, I think.
You are right, I was confused with
port install -bar
while in the port's directory
yves
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Default variants
Le 16 août 07 à 15:19, Yves de Champlain a écrit :
Le 07-08-16 à 08:49, N_Ox a écrit :
Le 16 août 07 à 13:47, Rainer Müller a écrit :
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
As I've said in the very first mail of this discussion, I don't
think recording disabled default variants is really a problem.
The only case it is one is during upgrade, and what I've said
should fix that.
It should also be noted that
port install foo -bar
will fail as -bar is not a recognized option.
yves
I've never had problem with that.
And you can always type `port install -- -foo`, I think.
--
Anthony Ramine, the infamous MacPorts Trac slave.
[EMAIL PROTECTED]
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Default variants
Yves de Champlain wrote: > It should also be noted that > > port install foo -bar > > will fail as -bar is not a recognized option. You are wrong, this works just fine. Try e.g. port install herrie -http It installs herrie without http support (which is normally enabled through default_variants). Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Default variants
Le 07-08-16 à 08:49, N_Ox a écrit :
Le 16 août 07 à 13:47, Rainer Müller a écrit :
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
As I've said in the very first mail of this discussion, I don't
think recording disabled default variants is really a problem.
The only case it is one is during upgrade, and what I've said
should fix that.
It should also be noted that
port install foo -bar
will fail as -bar is not a recognized option.
yves
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Default variants
Le 16 août 07 à 13:47, Rainer Müller a écrit :
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
As I've said in the very first mail of this discussion, I don't think
recording disabled default variants is really a problem.
The only case it is one is during upgrade, and what I've said should
fix that.
--
Anthony Ramine, the infamous MacPorts Trac slave.
[EMAIL PROTECTED]
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Default variants
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
Re: Default variants
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.
[EMAIL PROTECTED]
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Default variants
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,
--
Anthony Ramine, the infamous MacPorts Trac slave.
[EMAIL PROTECTED]
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
