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, 01:02 AM
Mike Frysinger
 
Default Feature request: package.use.stable.mask and package.use.stable.force

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
 
Old 04-27-2012, 04:43 AM
Jonathan Callen
 
Default Feature request: package.use.stable.mask and package.use.stable.force

-----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
Q3p01uowvTYhTx2mIh2qLPMemtJ1ABCe7ZxpTkconE1Qw9VtgK sjuRX63glnsKDh
wU6hzMH8RUFIA9BNDb4ZHstp35Okthtju67jPRiN2hp1DuYjTQ 4kTKm9IIp14/8T
hb9u7l2VEoyIuhYSAm1b1VjkIS5OO16tCkwiWF0HqaWCfw0z65/HncARf+D35cfZ
giHV9qwTvHoXCh2PBq7XyJaCs3XYcNfmAV7o8tBpXxAvzqWRbh 2hMLgSpmIxFjXM
3MvqdjVmNJowovAiLatHMby4ogO9Gq1A4svoYXsOuTC9lC4XQD p6md9zCcAPBD8w
qBEnixWb2p4xfqpzk0zP6JxmvQkKmPPzWVoBuV8lYni8jN/GFRntnT35GEwiA/si
04/wg3+w/cG4q5vglExrFpT3cNG8nkMPmqQIN8XrtdhGnOCyLYrAd4lvymE Vf4/8
ymD36BZwQ6xW3yjbWEl/CmvpdbRjrFBp5pzebFGzZxnWrrnGQtVBYYA4o7GoPvhu
hsNtCM/C8afynflTvaiX+9/bzbwrKSN5+4VmTT+9m+sQBwbnFy6iby1X5HlmE/Ie
L6k2iTxT0hrNxwZaf6eYR2zxjzV6FiDkO6eBEgYFNcOd+JgZ5/+dKJ/1CHy753d/
2zXMNmzVLT6fXLHrAH6m
=pmWk
-----END PGP SIGNATURE-----
 
Old 04-27-2012, 06:28 AM
Mike Frysinger
 
Default 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
 
Old 04-27-2012, 06:48 AM
Zac Medico
 
Default 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
 
Old 04-27-2012, 07:30 AM
Zac Medico
 
Default 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
 
Old 04-27-2012, 09:30 AM
Michael Haubenwallner
 
Default Feature request: package.use.stable.mask and package.use.stable.force

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
 

Thread Tools




All times are GMT. The time now is 03:38 AM.

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