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
04-27-2012, 04:43 AM
Jonathan Callen
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/
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
04-27-2012, 06:48 AM
Zac Medico
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
04-27-2012, 07:30 AM
Zac Medico
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
04-27-2012, 09:30 AM
Michael Haubenwallner
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.
Feature request: package.use.stable.mask and package.use.stable.force
