FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 04-27-2012, 07:36 PM
Zac Medico
 
Default 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
 
Old 04-27-2012, 07:57 PM
David Leverton
 
Default Feature request: package.use.stable.mask and package.use.stable.force

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.*
 
Old 04-27-2012, 11:37 PM
Zac Medico
 
Default Feature request: package.use.stable.mask and package.use.stable.force

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
 
Old 04-28-2012, 09:17 PM
Mike Frysinger
 
Default 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
 
Old 04-28-2012, 09:29 PM
Zac Medico
 
Default 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
 

Thread Tools




All times are GMT. The time now is 12:50 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org