On 17/09/2013 15:58, Duncan wrote:
Note that it wasn't JUST punctuation/capitalization that changed in the
given example, but the version number, 1.2.3 => 1.7.3, as well. Is that
still a trivial change?
Altho I'm not sure whether kensington changed the version number in his
example deliberately
Alexis Ballier schrieb:
> just to be clear: I prefer the 1st patch but I would give the variable
> (COMPLETE_MULTILIB) a more private name and document this is only for
> multilib-portage and it will not work with regular portage.
>
>
Since you only argued against such implementation in general,
Ian Stakenvicius schrieb:
> On 25/08/13 10:15 AM, Ulrich Mueller wrote:
>>> On Sun, 25 Aug 2013, Thomas Sachau wrote:
>
>>> workaround: add a variable, which changes the return of the
>>> function checking for the current ABI (always true with variable,
>>> without only true, when $ABI == $DEF
Thomas Sachau schrieb:
> Ulrich Mueller schrieb:
>>> On Sun, 25 Aug 2013, Thomas Sachau wrote:
>>
>>> workaround: add a variable, which changes the return of the function
>>> checking for the current ABI (always true with variable, without
>>> only true, when $ABI == $DEFAULT_ABI)
>>
>> Would t
> On Sun, 15 Sep 2013, Rich Freeman wrote:
> I didn't really get any response to this one way or another. At the
> last council meeting a majority of the votes were in favor of
> delaying taking action, so this is back on the agenda.
> I have yet to see either of the following on this list:
On Tue, 17 Sep 2013 14:38:08 +0200
Thomas Sachau wrote:
> Alexis Ballier schrieb:
> > just to be clear: I prefer the 1st patch but I would give the
> > variable (COMPLETE_MULTILIB) a more private name and document this
> > is only for multilib-portage and it will not work with regular
> > portage
On Tue, Sep 17, 2013 at 6:04 AM, Ulrich Mueller wrote:
>> On Sun, 15 Sep 2013, Rich Freeman wrote:
>
>> I didn't really get any response to this one way or another. At the
>> last council meeting a majority of the votes were in favor of
>> delaying taking action, so this is back on the agend
Hello, all.
I have committed today the eclass support code for python-exec:2,
and first package.mask-ed version of it. The benefits of the new
solution were explained in the earlier RFC mail [1]. Now for
the migration plan.
The eclasses cleanly support either version of the wrapper. They use :=
d
