Feature request: package.use.stable.mask and package.use.stable.force
 

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

Feature request: package.use.stable.mask and package.use.stable.force
 

>>>>> 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

Feature request: package.use.stable.mask and package.use.stable.force
 

-----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-----

Feature request: package.use.stable.mask and package.use.stable.force
 

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

Feature request: package.use.stable.mask and package.use.stable.force
 

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

Feature request: package.use.stable.mask and package.use.stable.force
 

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/

Feature request: package.use.stable.mask and package.use.stable.force
 

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/

Feature request: package.use.stable.mask and package.use.stable.force
 

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/

Feature request: package.use.stable.mask and package.use.stable.force
 

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/

Feature request: package.use.stable.mask and package.use.stable.force
 

-----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+Z87M6f10wAWc LIV5
RHd3591kyL5AOifaaM53/tgFcjvXECz+DfbDaVFaD1XjnSkEsu6aV6k1xaVqGGfF
pK3Dqo672XUKR1laFODYEkknO0JlR8EcU8De4pkdgj8ffbf0g2 uVXbpTCEgd+w4I
0eEd+LNVDAnTQntMuSETK5ysfYIVOPOmo1KoaR5XSFVsNL8Uzj UKY1Yx7owXrm+N
2OR+2JtdCnjkTveZZbP/Y8M74wiZeptOsgK5PxN+C/3vLWJ0LMrxIsWMugc0Oihv
3ddk1/WQolBtA8+DDBY+mOrJuKa5R7eqLAJQVmFLyDVLGu2dTCO26TaT 7IKWnN8J
Kw0RqscOFd93RcsfpgKwM2ij+8N+QlGgvK4qBwR9MAIEEQAPtx 5Rxi6dxly/b/7h
6jC2Yt8UqVOCloQ4vjoopIqA7QYGk3JS+yp27HAVR+cXDX1OWn tEU+LeVlmm27k9
vuEBRXosD9DpYCQ7OCQOzYa5TefgVs76TY/ygSgpkHlzcCbZ5iRwholKuOuKSvyd
mRi9g8/nctJXFkHn17GV
=LYAv
-----END PGP SIGNATURE-----