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.
(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.
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.
(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...
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.
(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.
(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.
(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?
(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.
Could the situation be improved by improving emerge's output?
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?
Maybe we should use package.keywords to achieve the desired result. That way, package.accept_keywords can retain its meaning of "accept testing keywords".
(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.
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(-)
*** Bug 739772 has been marked as a duplicate of this bug. ***
Closing this since everything is working as designed and intended.
