[gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force

[gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1385 bytes --]


Dear all, 

I'd like to suggest we introduce the following very useful feature, as soon as 
possible (which likely means in the next EAPI?):

* two new files in profile directories supported, package.use.stable.mask and 
package.use.stable.force
* syntax is identical to package.use.mask and package.use.force
* meaning is identical to package.use.mask and package.use.force, except that 
the resulting rules are ONLY applied iff a stable keyword is in use

Rationale: Often single features are "not ready for production yet", but the 
remaining package with that feature disabled would be a perfect candidate for 
stabilization. Right now this can be solved by 
* masking the useflag, which then makes the feature inaccessible even for 
~arch
* masking the useflag for exactly one package revision, which is hell to 
maintain
* or introducing different package revisions with/without the useflag, which 
is also a mess. 

Where this would (have been|be) useful:
* we had for a long time different revisions of subversion with/without kde 
useflag
* cups-1.4 had the infamous libusb backend triggered by USE=usb
* cups-1.5 has optional systemd support via a systemd useflag, which pulls in 
non-stabilized systemd as dependency...

Cheers, 
Andreas

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 677 bytes --]

On Thursday 26 April 2012 18:03:54 Andreas K. Huettel wrote:
> * two new files in profile directories supported, package.use.stable.mask
> and package.use.stable.force
> * syntax is identical to package.use.mask and package.use.force
> * meaning is identical to package.use.mask and package.use.force, except
> that the resulting rules are ONLY applied iff a stable keyword is in use

i'd love to see this as i'm tangling with pretty much the same problem: on 
ia64, we want java in ~arch, but never in stable (just don't have the 
resources for it).  this causes problems for packages that have USE=java and 
are stable, but work fine when they're unstable.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: Feature request: package.use.stable.mask and package.use.stable.force

[Jonathan Callen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 04/26/2012 06:03 PM, Andreas K. Huettel wrote:
> I'd like to suggest we introduce the following very useful
> feature, as soon as possible (which likely means in the next
> EAPI?):
> 
> * two new files in profile directories supported, 
> package.use.stable.mask and package.use.stable.force * syntax is 
> identical to package.use.mask and package.use.force * meaning is 
> identical to package.use.mask and package.use.force, except that 
> the resulting rules are ONLY applied iff a stable keyword is in 
> use

As "a stable keyword is in use" is either ambiguous or outright wrong
(depending on exactly what was meant by that), I would propose that
one of the following cases replace that:

* At least one keyword beginning with "~" or the value "**" is in the
global ACCEPT_KEYWORDS.
* At least one keyword beginning with "~" or the value "**" is in the
ACCEPT_KEYWORDS used for the package in question.

This is required because on a typical ~amd64 system, the effective
value of ACCEPT_KEYWORDS is "amd64 ~amd64" -- which would be covered
under "a stable keyword is in use" (the same applies for other arches
as well).

- -- 
Jonathan Callen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJPmiPhAAoJELHSF2kinlg4BRkP/2vxN8Wq9+tTdk54XifMm4T8
Q3p01uowvTYhTx2mIh2qLPMemtJ1ABCe7ZxpTkconE1Qw9VtgKsjuRX63glnsKDh
wU6hzMH8RUFIA9BNDb4ZHstp35Okthtju67jPRiN2hp1DuYjTQ4kTKm9IIp14/8T
hb9u7l2VEoyIuhYSAm1b1VjkIS5OO16tCkwiWF0HqaWCfw0z65/HncARf+D35cfZ
giHV9qwTvHoXCh2PBq7XyJaCs3XYcNfmAV7o8tBpXxAvzqWRbh2hMLgSpmIxFjXM
3MvqdjVmNJowovAiLatHMby4ogO9Gq1A4svoYXsOuTC9lC4XQDp6md9zCcAPBD8w
qBEnixWb2p4xfqpzk0zP6JxmvQkKmPPzWVoBuV8lYni8jN/GFRntnT35GEwiA/si
04/wg3+w/cG4q5vglExrFpT3cNG8nkMPmqQIN8XrtdhGnOCyLYrAd4lvymEVf4/8
ymD36BZwQ6xW3yjbWEl/CmvpdbRjrFBp5pzebFGzZxnWrrnGQtVBYYA4o7GoPvhu
hsNtCM/C8afynflTvaiX+9/bzbwrKSN5+4VmTT+9m+sQBwbnFy6iby1X5HlmE/Ie
L6k2iTxT0hrNxwZaf6eYR2zxjzV6FiDkO6eBEgYFNcOd+JgZ5/+dKJ/1CHy753d/
2zXMNmzVLT6fXLHrAH6m
=pmWk
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Feature request: package.use.stable.mask and package.use.stable.force

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1837 bytes --]

On Friday 27 April 2012 00:43:15 Jonathan Callen wrote:
> On 04/26/2012 06:03 PM, Andreas K. Huettel wrote:
> > I'd like to suggest we introduce the following very useful
> > feature, as soon as possible (which likely means in the next
> > EAPI?):
> > 
> > * two new files in profile directories supported,
> > package.use.stable.mask and package.use.stable.force * syntax is
> > identical to package.use.mask and package.use.force * meaning is
> > identical to package.use.mask and package.use.force, except that
> > the resulting rules are ONLY applied iff a stable keyword is in
> > use
> 
> As "a stable keyword is in use" is either ambiguous or outright wrong
> (depending on exactly what was meant by that), I would propose that
> one of the following cases replace that:
> 
> * At least one keyword beginning with "~" or the value "**" is in the
> global ACCEPT_KEYWORDS.
> * At least one keyword beginning with "~" or the value "**" is in the
> ACCEPT_KEYWORDS used for the package in question.
> 
> This is required because on a typical ~amd64 system, the effective
> value of ACCEPT_KEYWORDS is "amd64 ~amd64" -- which would be covered
> under "a stable keyword is in use" (the same applies for other arches
> as well).

i don't think that wording is correct and misses the point.  simple example of 
how this should work:

if package.use.stable.force has:
	cat/pkg foo

and then cat/pkg/pkg-0.ebuild has:
	KEYWORDS="~amd64 x86"

the forcing of "foo" would apply to people who are ARCH=x86 (regardless of 
their ACCEPT_KEYWORDS containing ~x86), but not apply to people who are 
ARCH=amd64.  once the ebuild changes to KEYWORDS="amd64 x86", then it would 
apply to both.

i.e. the keyword matching is to the ebuild, not to the user's ACCEPT_KEYWORDS.

or Andreas can clarify.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: Feature request: package.use.stable.mask and package.use.stable.force

[Zac Medico]

On 04/26/2012 11:28 PM, Mike Frysinger wrote:
> On Friday 27 April 2012 00:43:15 Jonathan Callen wrote:
>> On 04/26/2012 06:03 PM, Andreas K. Huettel wrote:
>>> I'd like to suggest we introduce the following very useful
>>> feature, as soon as possible (which likely means in the next
>>> EAPI?):
>>>
>>> * two new files in profile directories supported,
>>> package.use.stable.mask and package.use.stable.force * syntax is
>>> identical to package.use.mask and package.use.force * meaning is
>>> identical to package.use.mask and package.use.force, except that
>>> the resulting rules are ONLY applied iff a stable keyword is in
>>> use
>>
>> As "a stable keyword is in use" is either ambiguous or outright wrong
>> (depending on exactly what was meant by that), I would propose that
>> one of the following cases replace that:
>>
>> * At least one keyword beginning with "~" or the value "**" is in the
>> global ACCEPT_KEYWORDS.
>> * At least one keyword beginning with "~" or the value "**" is in the
>> ACCEPT_KEYWORDS used for the package in question.
>>
>> This is required because on a typical ~amd64 system, the effective
>> value of ACCEPT_KEYWORDS is "amd64 ~amd64" -- which would be covered
>> under "a stable keyword is in use" (the same applies for other arches
>> as well).
> 
> i don't think that wording is correct and misses the point.  simple example of 
> how this should work:
> 
> if package.use.stable.force has:
> 	cat/pkg foo
> 
> and then cat/pkg/pkg-0.ebuild has:
> 	KEYWORDS="~amd64 x86"
> 
> the forcing of "foo" would apply to people who are ARCH=x86 (regardless of 
> their ACCEPT_KEYWORDS containing ~x86), but not apply to people who are 
> ARCH=amd64.  once the ebuild changes to KEYWORDS="amd64 x86", then it would 
> apply to both.
> 
> i.e. the keyword matching is to the ebuild, not to the user's ACCEPT_KEYWORDS.

That makes sense in the context of trying to keep repoman from
complaining. Since repoman complains about stable keywords for packages
with unstable dependencies, package.use.stable.{force,mask} will serve
to mask off conditional dependencies that would otherwise trigger
*DEPEND.bad complaints from repoman.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Feature request: package.use.stable.mask and package.use.stable.force

[Zac Medico]

On 04/26/2012 11:48 PM, Zac Medico wrote:
> On 04/26/2012 11:28 PM, Mike Frysinger wrote:
>> On Friday 27 April 2012 00:43:15 Jonathan Callen wrote:
>>> On 04/26/2012 06:03 PM, Andreas K. Huettel wrote:
>>>> I'd like to suggest we introduce the following very useful
>>>> feature, as soon as possible (which likely means in the next
>>>> EAPI?):
>>>>
>>>> * two new files in profile directories supported,
>>>> package.use.stable.mask and package.use.stable.force * syntax is
>>>> identical to package.use.mask and package.use.force * meaning is
>>>> identical to package.use.mask and package.use.force, except that
>>>> the resulting rules are ONLY applied iff a stable keyword is in
>>>> use
>>>
>>> As "a stable keyword is in use" is either ambiguous or outright wrong
>>> (depending on exactly what was meant by that), I would propose that
>>> one of the following cases replace that:
>>>
>>> * At least one keyword beginning with "~" or the value "**" is in the
>>> global ACCEPT_KEYWORDS.
>>> * At least one keyword beginning with "~" or the value "**" is in the
>>> ACCEPT_KEYWORDS used for the package in question.
>>>
>>> This is required because on a typical ~amd64 system, the effective
>>> value of ACCEPT_KEYWORDS is "amd64 ~amd64" -- which would be covered
>>> under "a stable keyword is in use" (the same applies for other arches
>>> as well).
>>
>> i don't think that wording is correct and misses the point.  simple example of 
>> how this should work:
>>
>> if package.use.stable.force has:
>> 	cat/pkg foo
>>
>> and then cat/pkg/pkg-0.ebuild has:
>> 	KEYWORDS="~amd64 x86"
>>
>> the forcing of "foo" would apply to people who are ARCH=x86 (regardless of 
>> their ACCEPT_KEYWORDS containing ~x86), but not apply to people who are 
>> ARCH=amd64.  once the ebuild changes to KEYWORDS="amd64 x86", then it would 
>> apply to both.
>>
>> i.e. the keyword matching is to the ebuild, not to the user's ACCEPT_KEYWORDS.
> 
> That makes sense in the context of trying to keep repoman from
> complaining. Since repoman complains about stable keywords for packages
> with unstable dependencies, package.use.stable.{force,mask} will serve
> to mask off conditional dependencies that would otherwise trigger
> *DEPEND.bad complaints from repoman.

Actually, I don't think the specification should involve ARCH. In order
to determine whether package.use.stable.{force,mask} apply, I would
intersect KEYWORDS with ACCEPT_KEYWORDS, and apply
package.use.stable.{force,mask} if this intersection contains only
stable keywords. So, I think that I mostly agree with Jonathan's
statements, though I describe the behavior slightly differently than how
he did.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Feature request: package.use.stable.mask and package.use.stable.force

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 3235 bytes --]

On Friday 27 April 2012 03:30:43 Zac Medico wrote:
> On 04/26/2012 11:48 PM, Zac Medico wrote:
> > On 04/26/2012 11:28 PM, Mike Frysinger wrote:
> >> On Friday 27 April 2012 00:43:15 Jonathan Callen wrote:
> >>> On 04/26/2012 06:03 PM, Andreas K. Huettel wrote:
> >>>> I'd like to suggest we introduce the following very useful
> >>>> feature, as soon as possible (which likely means in the next
> >>>> EAPI?):
> >>>> 
> >>>> * two new files in profile directories supported,
> >>>> package.use.stable.mask and package.use.stable.force * syntax is
> >>>> identical to package.use.mask and package.use.force * meaning is
> >>>> identical to package.use.mask and package.use.force, except that
> >>>> the resulting rules are ONLY applied iff a stable keyword is in
> >>>> use
> >>> 
> >>> As "a stable keyword is in use" is either ambiguous or outright wrong
> >>> (depending on exactly what was meant by that), I would propose that
> >>> one of the following cases replace that:
> >>> 
> >>> * At least one keyword beginning with "~" or the value "**" is in the
> >>> global ACCEPT_KEYWORDS.
> >>> * At least one keyword beginning with "~" or the value "**" is in the
> >>> ACCEPT_KEYWORDS used for the package in question.
> >>> 
> >>> This is required because on a typical ~amd64 system, the effective
> >>> value of ACCEPT_KEYWORDS is "amd64 ~amd64" -- which would be covered
> >>> under "a stable keyword is in use" (the same applies for other arches
> >>> as well).
> >> 
> >> i don't think that wording is correct and misses the point.  simple
> >> example of how this should work:
> >> 
> >> if package.use.stable.force has:
> >> 	cat/pkg foo
> >> 
> >> and then cat/pkg/pkg-0.ebuild has:
> >> 	KEYWORDS="~amd64 x86"
> >> 
> >> the forcing of "foo" would apply to people who are ARCH=x86 (regardless
> >> of their ACCEPT_KEYWORDS containing ~x86), but not apply to people who
> >> are ARCH=amd64.  once the ebuild changes to KEYWORDS="amd64 x86", then
> >> it would apply to both.
> >> 
> >> i.e. the keyword matching is to the ebuild, not to the user's
> >> ACCEPT_KEYWORDS.
> > 
> > That makes sense in the context of trying to keep repoman from
> > complaining. Since repoman complains about stable keywords for packages
> > with unstable dependencies, package.use.stable.{force,mask} will serve
> > to mask off conditional dependencies that would otherwise trigger
> > *DEPEND.bad complaints from repoman.
> 
> Actually, I don't think the specification should involve ARCH. In order
> to determine whether package.use.stable.{force,mask} apply, I would
> intersect KEYWORDS with ACCEPT_KEYWORDS, and apply
> package.use.stable.{force,mask} if this intersection contains only
> stable keywords. So, I think that I mostly agree with Jonathan's
> statements, though I describe the behavior slightly differently than how
> he did.

wrt repoman, it doesn't know anything about ACCEPT_KEYWORDS

as for intersection, i don't think that works.  if my make.conf is:
	ACCEPT_KEYWORDS="amd64 ~amd64"
and i emerge a package that has:
	KEYWORDS="~amd64"

package.use.stable should not apply to this package.  it should only apply if 
it had:
	KEYWORDS="amd64"
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: Feature request: package.use.stable.mask and package.use.stable.force

[Zac Medico]

On 04/28/2012 02:17 PM, Mike Frysinger wrote:
> On Friday 27 April 2012 03:30:43 Zac Medico wrote:
>> On 04/26/2012 11:48 PM, Zac Medico wrote:
>>> On 04/26/2012 11:28 PM, Mike Frysinger wrote:
>>>> On Friday 27 April 2012 00:43:15 Jonathan Callen wrote:
>>>>> On 04/26/2012 06:03 PM, Andreas K. Huettel wrote:
>>>>>> I'd like to suggest we introduce the following very useful
>>>>>> feature, as soon as possible (which likely means in the next
>>>>>> EAPI?):
>>>>>>
>>>>>> * two new files in profile directories supported,
>>>>>> package.use.stable.mask and package.use.stable.force * syntax is
>>>>>> identical to package.use.mask and package.use.force * meaning is
>>>>>> identical to package.use.mask and package.use.force, except that
>>>>>> the resulting rules are ONLY applied iff a stable keyword is in
>>>>>> use
>>>>>
>>>>> As "a stable keyword is in use" is either ambiguous or outright wrong
>>>>> (depending on exactly what was meant by that), I would propose that
>>>>> one of the following cases replace that:
>>>>>
>>>>> * At least one keyword beginning with "~" or the value "**" is in the
>>>>> global ACCEPT_KEYWORDS.
>>>>> * At least one keyword beginning with "~" or the value "**" is in the
>>>>> ACCEPT_KEYWORDS used for the package in question.
>>>>>
>>>>> This is required because on a typical ~amd64 system, the effective
>>>>> value of ACCEPT_KEYWORDS is "amd64 ~amd64" -- which would be covered
>>>>> under "a stable keyword is in use" (the same applies for other arches
>>>>> as well).
>>>>
>>>> i don't think that wording is correct and misses the point.  simple
>>>> example of how this should work:
>>>>
>>>> if package.use.stable.force has:
>>>> 	cat/pkg foo
>>>>
>>>> and then cat/pkg/pkg-0.ebuild has:
>>>> 	KEYWORDS="~amd64 x86"
>>>>
>>>> the forcing of "foo" would apply to people who are ARCH=x86 (regardless
>>>> of their ACCEPT_KEYWORDS containing ~x86), but not apply to people who
>>>> are ARCH=amd64.  once the ebuild changes to KEYWORDS="amd64 x86", then
>>>> it would apply to both.
>>>>
>>>> i.e. the keyword matching is to the ebuild, not to the user's
>>>> ACCEPT_KEYWORDS.
>>>
>>> That makes sense in the context of trying to keep repoman from
>>> complaining. Since repoman complains about stable keywords for packages
>>> with unstable dependencies, package.use.stable.{force,mask} will serve
>>> to mask off conditional dependencies that would otherwise trigger
>>> *DEPEND.bad complaints from repoman.
>>
>> Actually, I don't think the specification should involve ARCH. In order
>> to determine whether package.use.stable.{force,mask} apply, I would
>> intersect KEYWORDS with ACCEPT_KEYWORDS, and apply
>> package.use.stable.{force,mask} if this intersection contains only
>> stable keywords. So, I think that I mostly agree with Jonathan's
>> statements, though I describe the behavior slightly differently than how
>> he did.
> 
> wrt repoman, it doesn't know anything about ACCEPT_KEYWORDS

It does know about ACCEPT_KEYWORDS because it generates them
automatically from KEYWORDS. The relevant code in /usr/bin/repoman looks
like this:

arches=[]
for keyword in myaux["KEYWORDS"].split():
	if (keyword[0]=="-"):
		continue
	elif (keyword[0]=="~"):
		arches.append([keyword, keyword[1:], [keyword[1:], keyword]])
	else:
		arches.append([keyword, keyword, [keyword]])
if not arches:
	# Use an empty profile for checking dependencies of
	# packages that have empty KEYWORDS.
	arches.append(['**', '**', ['**']])

> as for intersection, i don't think that works.  if my make.conf is:
> 	ACCEPT_KEYWORDS="amd64 ~amd64"
> and i emerge a package that has:
> 	KEYWORDS="~amd64"
> 
> package.use.stable should not apply to this package.  it should only apply if 
> it had:
> 	KEYWORDS="amd64"

See the algorithm that I've described here:

http://archives.gentoo.org/gentoo-dev/msg_6c492ae43ad7c70cef6aa8ac34911adf.xml

The case that you're talking about is equivalent to the 4th row of the
table in that message, and note that it says "no" in the package.stable
column, as you would expect.
-- 
Thanks,
Zac

Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force

[Michael Haubenwallner]

On 04/27/12 00:03, Andreas K. Huettel wrote:
>  as soon as possible (which likely means in the next EAPI?):
>
> * two new files in profile directories supported, package.use.stable.mask and
> package.use.stable.force
> * syntax is identical to package.use.mask and package.use.force
> * meaning is identical to package.use.mask and package.use.force, except that
> the resulting rules are ONLY applied iff a stable keyword is in use

Wouldn't it be more obvious/simple to have an extra profile subdirectory
containing package.use.mask and package.use.force?

Maybe in combination with 'eselect profile' to be able to select multiple
profiles [1], selecting both what /etc/make.profile pointed to as symlink
as well as some /usr/portage/profile/unstable/$arch - to avoid the need
for having an extra unstable/ subdir within each (selectable) profile dir.

Actually, I do have an extra unstable/ subdir for each selectable profile
here, besides an extra buildbot/ subdir too...

As a side effect, this wouldn't affect EAPI in any way.

[1] http://archives.gentoo.org/gentoo-dev/msg_a69bee8bfa00146ee05e49adf722e791.xml

my .02
/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 976 bytes --]

Am Freitag 27 April 2012, 11:30:57 schrieb Michael Haubenwallner:
> On 04/27/12 00:03, Andreas K. Huettel wrote:
> >  as soon as possible (which likely means in the next EAPI?):
> > * two new files in profile directories supported, package.use.stable.mask
> > and package.use.stable.force
> > * syntax is identical to package.use.mask and package.use.force
> > * meaning is identical to package.use.mask and package.use.force, except
> > that the resulting rules are ONLY applied iff a stable keyword is in use
> 
> Wouldn't it be more obvious/simple to have an extra profile subdirectory
> containing package.use.mask and package.use.force?

While this works (kind of), it is like running globally stable or globally 
testing. So, if you run stable but add one package with ~arch keyword, you are 
restricted to the "stable useflag set" there as well...


-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 597 bytes --]

On Fri, 27 Apr 2012 00:03:54 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
> * two new files in profile directories supported,
> package.use.stable.mask and package.use.stable.force
> * syntax is identical to package.use.mask and package.use.force
> * meaning is identical to package.use.mask and package.use.force,
> except that the resulting rules are ONLY applied iff a stable keyword
> is in use

This means that an ebuild will effectively change when moved from ~arch
to arch. The point of ~arch is to test ebuilds before they're moved to
arch.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force

[Chí-Thanh Christopher Nguyễn]

Ciaran McCreesh schrieb:
>> * two new files in profile directories supported,
>> package.use.stable.mask and package.use.stable.force
>> * syntax is identical to package.use.mask and package.use.force
>> * meaning is identical to package.use.mask and package.use.force,
>> except that the resulting rules are ONLY applied iff a stable keyword
>> is in use
> This means that an ebuild will effectively change when moved from ~arch
> to arch. The point of ~arch is to test ebuilds before they're moved to
> arch.

I agree that the ~arch ebuilds should be tested in the same
configuration in which they will end up in arch. However in this case,
the possible configurations for arch are a subset of those in ~arch, so
the testing covers those too.

I see a problem where a significant proportion of ~arch users will have
this flag enabled (which is obviously the point of
package.use.stable.mask) so the arch configurations will see fewer
testers. This issue may need to be addressed, e.g. by extending
stabilization period or disallowing package.use.stable.mask in default
or desktop profile.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force

[Ulrich Mueller]

>>>>> On Fri, 27 Apr 2012, Chí-Thanh Christopher Nguyễn wrote:

> Ciaran McCreesh schrieb:
>>> * two new files in profile directories supported,
>>> package.use.stable.mask and package.use.stable.force
>>> * syntax is identical to package.use.mask and package.use.force
>>> * meaning is identical to package.use.mask and package.use.force,
>>> except that the resulting rules are ONLY applied iff a stable keyword
>>> is in use
>> This means that an ebuild will effectively change when moved from
>> ~arch to arch. The point of ~arch is to test ebuilds before they're
>> moved to arch.

> I agree that the ~arch ebuilds should be tested in the same
> configuration in which they will end up in arch. However in this
> case, the possible configurations for arch are a subset of those in
> ~arch, so the testing covers those too.

Maybe I'm missing something, but what would happen when the newest
version of a package is marked stable? The masked USE flags would
become unavailable for everyone?

Ulrich

Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force

[Zac Medico]

On 04/27/2012 06:49 AM, Ulrich Mueller wrote:
>>>>>> On Fri, 27 Apr 2012, Chí-Thanh Christopher Nguyễn wrote:
> 
>> Ciaran McCreesh schrieb:
>>>> * two new files in profile directories supported,
>>>> package.use.stable.mask and package.use.stable.force
>>>> * syntax is identical to package.use.mask and package.use.force
>>>> * meaning is identical to package.use.mask and package.use.force,
>>>> except that the resulting rules are ONLY applied iff a stable keyword
>>>> is in use
>>> This means that an ebuild will effectively change when moved from
>>> ~arch to arch. The point of ~arch is to test ebuilds before they're
>>> moved to arch.
> 
>> I agree that the ~arch ebuilds should be tested in the same
>> configuration in which they will end up in arch. However in this
>> case, the possible configurations for arch are a subset of those in
>> ~arch, so the testing covers those too.
> 
> Maybe I'm missing something, but what would happen when the newest
> version of a package is marked stable? The masked USE flags would
> become unavailable for everyone?

In order to be practical, I guess we'd have to add a constraint which
says that if KEYWORDS contains the stable variant of a particular
keyword, then it should also be considered to implicitly contain the
unstable variant when the package manager is deciding whether or not to
apply package.use.{mask,force}.

So, here's a description of the whole algorithm that I'd use:

1) Let EFFECTIVE_KEYWORDS equal the set of values contained in KEYWORDS,
plus ** and all the unstable variants of the stable values contained in
KEYWORDS. For example:

   KEYWORDS="~amd64 x86" -> EFFECTIVE_KEYWORDS="~amd64 x86 ** ~x86"

2) Intersect EFFECTIVE_KEYWORDS with effective ACCEPT_KEYWORDS, where
effective ACCEPT_KEYWORDS includes any relevant values from
package.accept_keywords. For example, here is a table of intersections
of EFFECTIVE_KEYWORDS="~amd64 x86 ** ~x86" with various effective
ACCEPT_KEYWORDS values:

      ACCEPT_KEYWORDS  |  INTERSECTION  |  package.stable
     -----------------------------------------------------
      x86              |  x86           |  yes
      x86 ~x86         |  x86 ~x86      |  no
      **               |  **            |  no
      amd64 ~amd64     |  ~amd64        |  no

3) Apply package.stable settings if INTERSECTION contains only stable
keywords. For example, see the package.stable column in the table above.
-- 
Thanks,
Zac

Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1907 bytes --]

Am Freitag 27 April 2012, 17:26:48 schrieb Zac Medico:
> > 
> > Maybe I'm missing something, but what would happen when the newest
> > version of a package is marked stable? The masked USE flags would
> > become unavailable for everyone?
> 
> In order to be practical, I guess we'd have to add a constraint which
> says that if KEYWORDS contains the stable variant of a particular
> keyword, then it should also be considered to implicitly contain the
> unstable variant when the package manager is deciding whether or not to
> apply package.use.{mask,force}.
> 
> So, here's a description of the whole algorithm that I'd use:
> 
> 1) Let EFFECTIVE_KEYWORDS equal the set of values contained in KEYWORDS,
> plus ** and all the unstable variants of the stable values contained in
> KEYWORDS. For example:
> 
>    KEYWORDS="~amd64 x86" -> EFFECTIVE_KEYWORDS="~amd64 x86 ** ~x86"
> 
> 2) Intersect EFFECTIVE_KEYWORDS with effective ACCEPT_KEYWORDS, where
> effective ACCEPT_KEYWORDS includes any relevant values from
> package.accept_keywords. For example, here is a table of intersections
> of EFFECTIVE_KEYWORDS="~amd64 x86 ** ~x86" with various effective
> ACCEPT_KEYWORDS values:
> 
>       ACCEPT_KEYWORDS  |  INTERSECTION  |  package.stable
>      -----------------------------------------------------
>       x86              |  x86           |  yes
>       x86 ~x86         |  x86 ~x86      |  no
>       **               |  **            |  no
>       amd64 ~amd64     |  ~amd64        |  no
> 
> 3) Apply package.stable settings if INTERSECTION contains only stable
> keywords. For example, see the package.stable column in the table above.


That is the best description I've seen so far, which exactly describes the use 
case that I had in mind.  +1 :)


-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: Feature request: package.use.stable.mask and package.use.stable.force

[Jonathan Callen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 04/27/2012 11:26 AM, Zac Medico wrote:
> In order to be practical, I guess we'd have to add a constraint
> which says that if KEYWORDS contains the stable variant of a
> particular keyword, then it should also be considered to implicitly
> contain the unstable variant when the package manager is deciding
> whether or not to apply package.use.{mask,force}.
> 
> So, here's a description of the whole algorithm that I'd use:
> 
> 1) Let EFFECTIVE_KEYWORDS equal the set of values contained in
> KEYWORDS, plus ** and all the unstable variants of the stable
> values contained in KEYWORDS. For example:
> 
> KEYWORDS="~amd64 x86" -> EFFECTIVE_KEYWORDS="~amd64 x86 ** ~x86"
> 
> 2) Intersect EFFECTIVE_KEYWORDS with effective ACCEPT_KEYWORDS,
> where effective ACCEPT_KEYWORDS includes any relevant values from 
> package.accept_keywords. For example, here is a table of
> intersections of EFFECTIVE_KEYWORDS="~amd64 x86 ** ~x86" with
> various effective ACCEPT_KEYWORDS values:
> 
> ACCEPT_KEYWORDS  |  INTERSECTION  |  package.stable 
> ----------------------------------------------------- x86
> |  x86           |  yes x86 ~x86         |  x86 ~x86      |  no **
> |  **            |  no amd64 ~amd64     |  ~amd64        |  no
> 
> 3) Apply package.stable settings if INTERSECTION contains only
> stable keywords. For example, see the package.stable column in the
> table above.

This algorithm better matches what I meant in my earlier posting, so
+1 from me. (And if anyone has an ACCEPT_KEYWORDS value of "~amd64
- -amd64", they deserve any issues that may arise).

The only issue I have with it is that EFFECTIVE_KEYWORDS should be
expanded to contain "*" if any stable keyword is present and "~*" if
any unstable keyword is present (or "*" and "~*" in ACCEPT_KEYWORDS
should be pre-expanded).
- -- 
Jonathan Callen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJPmvKPAAoJELHSF2kinlg43ZgP/1F++FzGzmUZxy+2enHeCIRb
47y4hFxZG18ulWijr0qEJTizDGCxE8RCBfanM4I1G4qSdy0Eyg+6yIdT+B1FRZ1F
Wp5p/CPPX/AfxgJ+LTTmY5V3f8AWrk1MfX4sGoy+0DGzgMB+Z87M6f10wAWcLIV5
RHd3591kyL5AOifaaM53/tgFcjvXECz+DfbDaVFaD1XjnSkEsu6aV6k1xaVqGGfF
pK3Dqo672XUKR1laFODYEkknO0JlR8EcU8De4pkdgj8ffbf0g2uVXbpTCEgd+w4I
0eEd+LNVDAnTQntMuSETK5ysfYIVOPOmo1KoaR5XSFVsNL8UzjUKY1Yx7owXrm+N
2OR+2JtdCnjkTveZZbP/Y8M74wiZeptOsgK5PxN+C/3vLWJ0LMrxIsWMugc0Oihv
3ddk1/WQolBtA8+DDBY+mOrJuKa5R7eqLAJQVmFLyDVLGu2dTCO26TaT7IKWnN8J
Kw0RqscOFd93RcsfpgKwM2ij+8N+QlGgvK4qBwR9MAIEEQAPtx5Rxi6dxly/b/7h
6jC2Yt8UqVOCloQ4vjoopIqA7QYGk3JS+yp27HAVR+cXDX1OWntEU+LeVlmm27k9
vuEBRXosD9DpYCQ7OCQOzYa5TefgVs76TY/ygSgpkHlzcCbZ5iRwholKuOuKSvyd
mRi9g8/nctJXFkHn17GV
=LYAv
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Feature request: package.use.stable.mask and package.use.stable.force

[Zac Medico]

On 04/27/2012 12:25 PM, Jonathan Callen wrote:
> On 04/27/2012 11:26 AM, Zac Medico wrote:
>> In order to be practical, I guess we'd have to add a constraint
>> which says that if KEYWORDS contains the stable variant of a
>> particular keyword, then it should also be considered to implicitly
>> contain the unstable variant when the package manager is deciding
>> whether or not to apply package.use.{mask,force}.
> 
>> So, here's a description of the whole algorithm that I'd use:
> 
>> 1) Let EFFECTIVE_KEYWORDS equal the set of values contained in
>> KEYWORDS, plus ** and all the unstable variants of the stable
>> values contained in KEYWORDS. For example:
> 
>> KEYWORDS="~amd64 x86" -> EFFECTIVE_KEYWORDS="~amd64 x86 ** ~x86"
> 
>> 2) Intersect EFFECTIVE_KEYWORDS with effective ACCEPT_KEYWORDS,
>> where effective ACCEPT_KEYWORDS includes any relevant values from 
>> package.accept_keywords. For example, here is a table of
>> intersections of EFFECTIVE_KEYWORDS="~amd64 x86 ** ~x86" with
>> various effective ACCEPT_KEYWORDS values:
> 
>> ACCEPT_KEYWORDS  |  INTERSECTION  |  package.stable 
>> ----------------------------------------------------- x86
>> |  x86           |  yes x86 ~x86         |  x86 ~x86      |  no **
>> |  **            |  no amd64 ~amd64     |  ~amd64        |  no
> 
>> 3) Apply package.stable settings if INTERSECTION contains only
>> stable keywords. For example, see the package.stable column in the
>> table above.
> 
> This algorithm better matches what I meant in my earlier posting, so
> +1 from me. (And if anyone has an ACCEPT_KEYWORDS value of "~amd64
> -amd64", they deserve any issues that may arise).
> 
> The only issue I have with it is that EFFECTIVE_KEYWORDS should be
> expanded to contain "*" if any stable keyword is present and "~*" if
> any unstable keyword is present (or "*" and "~*" in ACCEPT_KEYWORDS
> should be pre-expanded).

Yeah, I omitted * and ~* for brevity, and you've got the right idea.
-- 
Thanks,
Zac

Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force

[David Leverton]

Zac Medico wrote:
> So, here's a description of the whole algorithm that I'd use:
 > [snip]

I think the following is equivalent, but simpler and more general since 
it doesn't have to mention details like ** and friends that aren't 
currently in PMS, and doesn't assume that the rule for handling KEYWORDS 
is simply "does it contain at least one of the accepted values? (plus 
handling of ** etc)".  (For example, I can imagine something like 
"accept the package if it has amd64, or if it has both ~amd64 and x86" 
being potentially useful for some people, although I don't think it's 
implemented anywhere at the moment.)

1) Pretend that all stable keywords in the package's KEYWORDS are 
replaced with the corresponding ~arch ones
2) If this would result in the package being masked by keywords (I 
forget the exact terminology Portage uses, but I'm sure you know what I 
mean), then apply the masks/forces from package.use.stable.*

Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force

[Zac Medico]

On 04/27/2012 12:57 PM, David Leverton wrote:
> Zac Medico wrote:
>> So, here's a description of the whole algorithm that I'd use:
>> [snip]
> 
> I think the following is equivalent, but simpler and more general since
> it doesn't have to mention details like ** and friends that aren't
> currently in PMS, and doesn't assume that the rule for handling KEYWORDS
> is simply "does it contain at least one of the accepted values? (plus
> handling of ** etc)".  (For example, I can imagine something like
> "accept the package if it has amd64, or if it has both ~amd64 and x86"
> being potentially useful for some people, although I don't think it's
> implemented anywhere at the moment.)
> 
> 1) Pretend that all stable keywords in the package's KEYWORDS are
> replaced with the corresponding ~arch ones
> 2) If this would result in the package being masked by keywords (I
> forget the exact terminology Portage uses, but I'm sure you know what I
> mean), then apply the masks/forces from package.use.stable.*

Yeah, that appears to be equivalent.
-- 
Thanks,
Zac

Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force

[Rich Freeman]

On Fri, Apr 27, 2012 at 7:35 AM, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
> I agree that the ~arch ebuilds should be tested in the same
> configuration in which they will end up in arch. However in this case,
> the possible configurations for arch are a subset of those in ~arch, so
> the testing covers those too.

Just because a stable system brings in fewer use flags doesn't
necessarily mean that it is less likely to break.  Use flags can have
all kinds of effects, some applied when they are present, and others
applied when they are absent.

The value of testing comes from testing things in the anticipated
future production environment.  Of course, the fact that we stabilize
individual packages and not all their libraries/etc at the same time
already weakens this.

Rich

Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1990 bytes --]

Am Freitag 27 April 2012, 13:35:21 schrieb Chí-Thanh Christopher Nguyễn:
> Ciaran McCreesh schrieb:
> >> * two new files in profile directories supported,
> >> package.use.stable.mask and package.use.stable.force
> >> * syntax is identical to package.use.mask and package.use.force
> >> * meaning is identical to package.use.mask and package.use.force,
> >> except that the resulting rules are ONLY applied iff a stable keyword
> >> is in use
> > 
> > This means that an ebuild will effectively change when moved from ~arch
> > to arch. The point of ~arch is to test ebuilds before they're moved to
> > arch.
> 
> I agree that the ~arch ebuilds should be tested in the same
> configuration in which they will end up in arch. However in this case,
> the possible configurations for arch are a subset of those in ~arch, so
> the testing covers those too.

Right now, it's more likely that just before filing the stablerequest an 
ebuild is modified such that the useflag disappears and all the conditional 
codeblocks are set to a fixed value. (Compare cups-1.5.2-r3 and -r4) That 
includes a much larger danger of mistakes creeping in.

Just forcing an useflag on or off poses a fairly minimal intrusion.

> I see a problem where a significant proportion of ~arch users will have
> this flag enabled (which is obviously the point of
> package.use.stable.mask) so the arch configurations will see fewer
> testers. This issue may need to be addressed, e.g. by extending
> stabilization period or disallowing package.use.stable.mask in default
> or desktop profile.

Well, at least in some use cases the useflag will have an obvious disadvantage 
(remember the many libusb-backend bugs in cups-1.4). Then the consensus would 
have been "you can use this but it's not as bug-free", there may have been 
even an ewarn about it, ...

Cheers, 
Andreas

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 26/04/12 06:03 PM, Andreas K. Huettel wrote:
> 
> Dear all,
> 
> I'd like to suggest we introduce the following very useful feature,
> as soon as possible (which likely means in the next EAPI?):
> 
> * two new files in profile directories supported,
> package.use.stable.mask and package.use.stable.force * syntax is
> identical to package.use.mask and package.use.force * meaning is
> identical to package.use.mask and package.use.force, except that 
> the resulting rules are ONLY applied iff a stable keyword is in
> use
> 
> Rationale: Often single features are "not ready for production
> yet", but the remaining package with that feature disabled would be
> a perfect candidate for stabilization. Right now this can be solved
> by * masking the useflag, which then makes the feature inaccessible
> even for ~arch * masking the useflag for exactly one package
> revision, which is hell to maintain * or introducing different
> package revisions with/without the useflag, which is also a mess.


I would think, personally, that masking the useflag on a per-package
basis would be better than this new feature -- it is more work as it
needs to be done for all the different ~arch packages the use flag
applies to, but it would mean that when a given ~arch version bump has
that feature ready one wouldn't lose the mask on the previous ~arch
versions.  It would also mean (i assume) that this flag would be
masked if that version went stable too (although in reality I would
expect this wouldn't ever occur).

There are potentially a lot of package entries to manage if this were,
say, a flag like 'introspection'..  however, i'm sure maintaining this
could be scriptable couldn't it?


> 
> Where this would (have been|be) useful: * we had for a long time
> different revisions of subversion with/without kde useflag *
> cups-1.4 had the infamous libusb backend triggered by USE=usb *
> cups-1.5 has optional systemd support via a systemd useflag, which
> pulls in non-stabilized systemd as dependency...
> 

I'm not sure that I'm following the cups examples here.  For cups-1.5
even if it were stable, if someone actually wanted to use systemd on
their system and unmasked/keyworded it (while running stable
everything else) I don't see why this would be an issue that would
need this new masking feature (unless IUSE="+systemd", which probably
shouldn't be the case anyways).

Ian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk+ara4ACgkQ2ugaI38ACPALZwD/bIk3GzOThs6P/2EkWn2DxvEY
XHQZVUvmc1dJBERmSiIA/3saDFCoK79S8fw+2Q9Myf9Lt6PdEc4u1j48QcDf+sKW
=XQ3/
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1059 bytes --]

Am Freitag 27 April 2012, 16:31:10 schrieb Ian Stakenvicius:
 
> > Where this would (have been|be) useful: * we had for a long time
> > different revisions of subversion with/without kde useflag *
> > cups-1.4 had the infamous libusb backend triggered by USE=usb *
> > cups-1.5 has optional systemd support via a systemd useflag, which
> > pulls in non-stabilized systemd as dependency...
> 
> I'm not sure that I'm following the cups examples here.  For cups-1.5
> even if it were stable, if someone actually wanted to use systemd on
> their system and unmasked/keyworded it (while running stable
> everything else) I don't see why this would be an issue that would
> need this new masking feature (unless IUSE="+systemd", which probably
> shouldn't be the case anyways).

The point is that as it is now cups(-1.5.2-r20) could not be stabilized 
without a stable systemd, because systemd is a dependency (optional on useflag 
systemd).

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]