Summary: | use.stable.mask is applied using packages' ACCEPT_KEYWORDS rather than the global one | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Michał Górny <mgorny> |
Component: | Core - Ebuild Support | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | alexander, dilfridge, franz.trischberger, kingjon3377, mattst88, mbucas, mike.desimone, mike, pacho |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=490816 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 607852 | ||
Bug Blocks: |
Description
Michał Górny
2013-11-13 13:19:30 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. 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. |