Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 491166 - use.stable.mask is applied using packages' ACCEPT_KEYWORDS rather than the global one
Summary: use.stable.mask is applied using packages' ACCEPT_KEYWORDS rather than the gl...
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Ebuild Support (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 739772 (view as bug list)
Depends on: 607852
Blocks:
  Show dependency tree
 
Reported: 2013-11-13 13:19 UTC by Michał Górny
Modified: 2020-09-22 16:22 UTC (History)
9 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-11-13 13:19:30 UTC
Currently, portage is applying use.stable.mask using package-local ACCEPT_KEYWORDS rather than the global one. As a result, testing packages that are unmasked using package.accept_keywords on a stable system get the full set of USE flags rather than only those destined for stable-profile system.

Long story short, people unexpectedly end up applying testing keywords to a lot of packages in order to satisfy USE flags that were supposed to be masked. Worse than that, people actually try to unmask the flags via adding packages to package.accept_keywords.

I think portage should use only the 'global' ACCEPT_KEYWORDS value to mask USE flags. If people need testing flags on a stable system, they should properly unmask them via local use.stable.mask. If people want to access testing version of a package on a stable system, they should get only that and no additional USE flags.
Comment 1 Andreas K. Hüttel archtester gentoo-dev 2013-11-13 13:22:02 UTC
(In reply to Michał Górny from comment #0)
> Currently, portage is applying use.stable.mask using package-local
> ACCEPT_KEYWORDS rather than the global one. As a result, testing packages
> that are unmasked using package.accept_keywords on a stable system get the
> full set of USE flags rather than only those destined for stable-profile
> system.
> 
> Long story short, people unexpectedly end up applying testing keywords to a
> lot of packages in order to satisfy USE flags that were supposed to be
> masked. Worse than that, people actually try to unmask the flags via adding
> packages to package.accept_keywords.

Actually, being able to do that was a design decision at the start; it's not an accident.
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-11-13 14:15:07 UTC
Then it was simply a wrong decision. It's nowhere near least surprise.

If I unmask a testing version of a package on a stable system, I usually have to. It's not that I instantly want to turn my system into half-stable, half-testing.

Now, the unmask may result in python3.3 instantly becoming unmasked. 'Nice', I think, and I enable it. I see that I need to unmask python. But then portage randomly wants to turn some more random packages to testing just to unmask the flag that *would work fine* if I used the stable versions with just the flag unmasked.

Long story short, people either end up having much more testing packages than they'd expect or start playing with package.accept_keywords per-version and then complain to the mailing list that their lives have been turned into nightmares.
Comment 3 Andreas K. Hüttel archtester gentoo-dev 2013-11-13 14:28:29 UTC
(In reply to Michał Górny from comment #2)
> Then it was simply a wrong decision. It's nowhere near least surprise.
> 
> If I unmask a testing version of a package on a stable system, I usually
> have to. It's not that I instantly want to turn my system into half-stable,
> half-testing.
> 
> Now, the unmask may result in python3.3 instantly becoming unmasked. 'Nice',
> I think, and I enable it. I see that I need to unmask python. But then
> portage randomly wants to turn some more random packages to testing just to
> unmask the flag that *would work fine* if I used the stable versions with
> just the flag unmasked.

Sorry if this comes over as a flamebait, but maybe it was a bad design decision to use USE-flags for python versions then?! There's always two sides to a story...
Comment 4 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-11-17 21:23:39 UTC
For future reference: this already results in mistakes being done by arch testers.

Like in bug 490816:

> Elijah "Armageddon" El Lazkani (amd64 AT)  archtester 2013-11-17 05:15:57 UTC requires:
> =dev-python/setuptools-1.1.6
> =dev-python/pypy-2.0.2
> =virtual/pypy-2.0.2

where pypy-2.0 is stable-masked and therefore not actually necessary for the stabilization.
Comment 5 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-11-17 21:38:21 UTC
(In reply to Michał Górny from comment #4)
> For future reference: this already results in mistakes being done by arch
> testers.

This can be prevented by using repoman, which arch testers like ago do (they have previously provided its output when dependency bugs missed); there are quite some other errors that can be made without it, this one isn't a special exception.
Comment 6 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-11-17 21:41:06 UTC
(In reply to Tom Wijsman (TomWij) from comment #5)
> (In reply to Michał Górny from comment #4)
> > For future reference: this already results in mistakes being done by arch
> > testers.
> 
> This can be prevented by using repoman, which arch testers like ago do (they
> have previously provided its output when dependency bugs missed); there are
> quite some other errors that can be made without it, this one isn't a
> special exception.

repoman won't tell you that you try to stabilize too many packages.
Comment 7 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-11-17 21:57:48 UTC
(In reply to Michał Górny from comment #6)
> repoman won't tell you that you try to stabilize too many packages.

Stabilizing too many means repoman isn't used; follow repoman, this won't happen.

Why stabilize more dependencies than repoman requires you to?
Comment 8 Mike Nerone 2013-11-18 07:34:08 UTC
(In reply to Andreas K. Hüttel from comment #3)
> Sorry if this comes over as a flamebait, but maybe it was a bad design
> decision to use USE-flags for python versions then?! There's always two
> sides to a story...

This is a form of straw man argument, being dismissive of the overall problem by attacking the specifics of just one example.
Comment 9 Sebastian Luther (few) 2014-06-09 19:30:20 UTC
Could the situation be improved by improving emerge's output?
Comment 10 Franz Trischberger 2020-01-07 17:09:08 UTC
On gentoo-user this just caused confusion. (Unfortunately I can't find that message on archives.gentoo.org, most of the january messages are missing there - is this a bug?)

dev-python/olefile-0.46 is stable on amd64.
Adding dev-python/olefile to package.accept_keywords unmasks the python_targets_python3_7 USE-Flag, which the user has enabled via make.conf.

I would have expected that use.stable.mask stays active for stable packages. Unmasking such USE-Flags would require additional steps. Especially I would never have thought that I could internally flag a stable package testing with an entry in package.accept_keywords. Or do I just not understand the meaning of KEYWORDS and package.accept_keywords?

Is this really intentional?
Comment 11 Zac Medico gentoo-dev 2020-01-07 17:55:32 UTC
Maybe we should use package.keywords to achieve the desired result. That way, package.accept_keywords can retain its meaning of "accept testing keywords".
Comment 12 Zac Medico gentoo-dev 2020-01-07 17:59:52 UTC
(In reply to Zac Medico from comment #11)
> Maybe we should use package.keywords to achieve the desired result. That
> way, package.accept_keywords can retain its meaning of "accept testing
> keywords".

Though /etc/portage/package.keywords doesn't work for this (it has the same meaning as package.accept_keywords for legacy reasons), it's already possible to use /etc/portage/profile/package.keywords to achieve the desired result.
Comment 13 Larry the Git Cow gentoo-dev 2020-01-23 06:04:43 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/portage.git/commit/?id=7e50a057958624dd728e858a3c07517240f85d02

commit 7e50a057958624dd728e858a3c07517240f85d02
Author:     Zac Medico <zmedico@gentoo.org>
AuthorDate: 2020-01-18 06:06:27 +0000
Commit:     Zac Medico <zmedico@gentoo.org>
CommitDate: 2020-01-23 06:01:14 +0000

    UserWarning if /etc/portage/package.keywords exists
    
    The /etc/portage/package.keywords file has been long deprecated
    in favor of /etc/portage/package.accept_keywords. The file would
    be useful if we could make it behave like package.keywords in
    profiles (see bug 491166), but it's safest if we trigger a
    UserWarning for some time before we change the meaning in a
    future version of portage. The message looks like this:
    
    UserWarning: /etc/portage/package.keywords is deprecated, use /etc/portage/package.accept_keywords instead
    
    Bug: https://bugs.gentoo.org/491166
    Bug: https://bugs.gentoo.org/607852
    Signed-off-by: Zac Medico <zmedico@gentoo.org>

 lib/portage/package/ebuild/_config/KeywordsManager.py | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)
Comment 14 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2020-09-22 16:22:58 UTC
*** Bug 739772 has been marked as a duplicate of this bug. ***