FEATURES="test" forces USE="test" as expected but FEATURES="-test" doesn't force USE="-test". The expected behaviour for portage would be to always ignore USE="test" or even better complain if a user sets USE="test" / USE="-test" either on command line or through package.use / make.conf. The edge case USE="-*" should be considered when implementing this. The preferred way to display the test useflag in emerge -pv output would be the same as a masked respectively forced useflag.
(In reply to comment #0) > The expected behaviour for portage would be to always ignore USE="test" or even > better complain if a user sets USE="test" / USE="-test" either on command line > or through package.use / make.conf. If we add additional coupling between FEATURES=test and USE=test, it complicates the code without necessarily providing any really practical value. That fact that FEATURES=test happens to enable USE=test is really just to ensure that src_test dependencies are satisfied when appropriate. It works fine as it is. Sometimes people enable USE=test globally in order to avoid having FEATURES=test interact with emerge --newuse behavior, since they have it configured such that USE=test is enabled whether or not FEATURES=test is enabled. If we implement your suggestion, it seems like it might interfere with this use case.
A user either wants to run src_test or not. Portage complaining about USE="test" in the form of 'Use FEATURES="test" to enable optional tests (often unit tests).' would prevent a lot of confusion in the first place. As the useflag description says it's a workaround to pull in test dependencies only if needed. Many say it shouldn't be a useflag at all. I agree, but unconditionally depending on test dependencies isn't an option either. So I believe test should be treated as a useflag only where needed, ie. within ebuilds/eclasses. Fully linking the value of 'use test' with FEATURES="test" would also allow to reliably tell whether src_test will be run from within the ebuild in a package manager independent form. This could well have some use cases. Could be an item for a future EAPI. (In reply to comment #1) > > Sometimes people enable USE=test globally in order to avoid having > FEATURES=test interact with emerge --newuse behavior, since they have it > configured such that USE=test is enabled whether or not FEATURES=test is > enabled. If we implement your suggestion, it seems like it might interfere with > this use case. It seems to me that the motivation for this case was the lack of per package env configuration. See https://bugs.gentoo.org/show_bug.cgi?id=193946#c2 The case FEATURES="-test" USE="test", which unexperienced users might come up unintentionally, will pull a lot of stuff with no gain at all or even worse create circular deps and other minor issues.
I like the idea, and have a couple of requirements to add: 1) Behavior of options like emerge --newuse will be entirely independent of the "test" flag state. 2) All USE flag displays will have to display the "test" flag in a way that makes it distinguishable from normal, masked, and forced flags.
Didn't took long to find an example where the behaviour described in in here would have helped. http://forums.gentoo.org/viewtopic-t-885952-highlight-.html (In reply to comment #3) > I like the idea, and have a couple of requirements to add: > > 1) Behavior of options like emerge --newuse will be entirely independent of the > "test" flag state. > > 2) All USE flag displays will have to display the "test" flag in a way that > makes it distinguishable from normal, masked, and forced flags. If you already intend to have a new way to display the "test" flag, you might think up something which potentially could handle other special use flags as well. "arch" and "libc" useflags for instance would be kind of similar in nature.
Well, the arch and libc flags are close enough to use.force since they're never supposed to change. In fact, the profiles have those flags in use.force already.
(In reply to comment #5) > Well, the arch and libc flags are close enough to use.force since they're never > supposed to change. In fact, the profiles have those flags in use.force > already. In case of arch and libc I'm thinking about cross root support. So them changing is in principle valid. The difference is one is forced by FEATURES, the other by profile. Depending on what you had in mind they do or do not fit together. I don't mind either way.
*** Bug 193946 has been marked as a duplicate of this bug. ***
*** Bug 198640 has been marked as a duplicate of this bug. ***
*** Bug 341655 has been marked as a duplicate of this bug. ***
This is fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=6b19f71b39b6af43307abf20654511bace041217 The "test" flag will show as {test} or {-test} in the emerge output, in order to indicate that it is bound to the FEATURES setting. Also, options like emerge --newuse will ignore the state of USE=test, since users typically don't want to trigger a bunch of rebuilds when they enable or disable FEATURES=test.
This is fixed in 2.1.11.17 and 2.2.0_alpha128.
We've got a new approach, involving USE_ORDER: https://gitweb.gentoo.org/proj/portage.git/commit/?id=8c5598c1af2c4c96546f196e2213211ec9cd7e7a commit 8c5598c1af2c4c96546f196e2213211ec9cd7e7a Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2017-06-04 10:21:45 +0200 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2018-07-31 19:24:02 +0200 Replace implicit {FEATURES->USE}=test forcing with USE default Use an explicit USE_ORDER entry to control mapping FEATURES=test into default-enabled USE=test, rather than forcing/masking it depending on the state of FEATURES. This makes it possible for users to enable (or disable) USE=test independently of FEATURES. An example use case is installing test dependencies and building test cases without actually running tests at a particular moment which is something I've been doing quite frequently with LLVM. Reviewed-by: Zac Medico <zmedico@gentoo.org> Closes: https://github.com/gentoo/portage/pull/347
