[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Re: Feature request: package.use.stable.mask and package.use.stable.force
From:       Zac Medico <zmedico () gentoo ! org>
Date:       2012-04-28 21:29:42
Message-ID: 4F9C6146.9010306 () gentoo ! org
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]