Re: [gentoo-dev] Re: Feature request: package.use.stable.mask and package.use.stable.force
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
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Feature request: package.use.stable.mask and package.use.stable.force
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] Re: Feature request: package.use.stable.mask and package.use.stable.force
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Feature request: package.use.stable.mask and package.use.stable.force
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
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
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
