| Summary: | EAPI 5 does not have special case for "test" USE flag | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Nikoli <nikoli> |
| Component: | Unclassified | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | floppym, mgorny, pms, pva, rhill |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 912975 | ||
| Attachments: | build.log | ||
|
Description
Nikoli
2013-01-31 10:03:46 UTC
Masking USE=test is not a method of disabling tests. In order to disable tests, you need to set FEATURES=-test. You can use /etc/portage/env for that. Portage profiles use it, why users should not use it in local profiles? $ grep test$ `find profiles/ -name package.use.mask`|wc -l 26 Also are you sure you did not break package.use.mask from /usr/portage/profiles/? (In reply to comment #2) > Portage profiles use it, why users should not use it in local profiles? > $ grep test$ `find profiles/ -name package.use.mask`|wc -l > 26 > > Also are you sure you did not break package.use.mask from > /usr/portage/profiles/? I have no idea how people used it and how it was supposed to work. It seems to me like a completely fragile thing which was never defined by the PMS. If it worked, good for you. If it didn't, I wouldn't be surprised. Feel free to provide a patch if you know how it should work. Zac, please explain, what is now correct way of masking tests per package in global (portage tree, overlays) and local profiles? Should masking with profile/package.use.mask be supported? This appears to be a change in portage behavior caused by setting EAPI=5. With EAPI=4, masking the test USE flag will disable the test phase, regardless of the contents of IUSE. With EAPI=5, masking the test USE flag only disables the test phase if the ebuild happens to set IUSE="test". (In reply to comment #5) > This appears to be a change in portage behavior caused by setting EAPI=5. > > With EAPI=4, masking the test USE flag will disable the test phase, > regardless of the contents of IUSE. > > With EAPI=5, masking the test USE flag only disables the test phase if the > ebuild happens to set IUSE="test". If that's the case, then it's due to implicit USE flags change. In EAPI 5, the ebuild does no longer contain a random bunch of profile-injected flags. (In reply to comment #6) That was my thought as well. Maybe we should add "test" to IUSE_IMPLICIT in the base profile? (In reply to comment #4) > Zac, please explain, what is now correct way of masking tests per package in > global (portage tree, overlays) and local profiles? Should masking with > profile/package.use.mask be supported? You can use /etc/portage/package.env, like this: echo 'FEATURES="-test"' > /etc/portage/env/no_test.conf echo 'dev-python/setuptools no_test.conf' >> /etc/portage/package.env (In reply to comment #7) > (In reply to comment #6) > > That was my thought as well. Maybe we should add "test" to IUSE_IMPLICIT in > the base profile? Not sure if it's really necessary, give the above approach. You could also use package.env to enable FEATURES=test-fail-continue selectively. Please add. Reasons: 1) If it worked and was used, why break? Was there any announce about this breakage? I think no. 2) package.env seems fine for local /etc/portage/, but not for profiles in overlays and portage tree. In portage tree it is possible to mask tests for some arch by editing RESTRICT in ebuild, but in overlay it is better to use package.use.mask when ebuild is in portage tree only. Copying ebuild to overlay and keeping it in sync with portage tree changes only for custom RESTRICT seems not best approach. 3) Using package.use.mask is just simpler: creating file with custom env variables and then sourcing it via second file vs just masking one USE flag by adding one line to one file. (In reply to comment #10) > Please add. Reasons: > 1) If it worked and was used, why break? Was there any announce about this > breakage? I think no. Well, it was discussed in the sense that IUSE_IMPLICIT was discussed. But no, the affect that it would have on people who rely on package.use.mask to disable tests was not discussed (to my knowledge). > 3) Using package.use.mask is just simpler: creating file with custom env > variables and then sourcing it via second file vs just masking one USE flag > by adding one line to one file. IUSE_IMPLICIT changes really should be discussed on the gentoo-dev mailing list, because they will affect the policy for what needs to be explicitly listed in IUSE for *all* ebuilds. (In reply to comment #10) > Please add. Reasons: > 1) If it worked and was used, why break? Was there any announce about this > breakage? I think no. How do you know that it worked? Maybe it worked only for the few people who actually used it? Did it work in pkgcore and paludis? > 2) package.env seems fine for local /etc/portage/, but not for profiles in > overlays and portage tree. > In portage tree it is possible to mask tests for some arch by editing > RESTRICT in ebuild, but in overlay it is better to use package.use.mask when > ebuild is in portage tree only. Copying ebuild to overlay and keeping it in > sync with portage tree changes only for custom RESTRICT seems not best > approach. Restricting tests per-arch is not a good idea. That usually means that someone is masking failures and pretending that something does work properly. > 3) Using package.use.mask is just simpler: creating file with custom env > variables and then sourcing it via second file vs just masking one USE flag > by adding one line to one file. How simpler? We're talking about creating one file in /etc/portage/env once and using it in /etc/portage/package.env vs creating a local profile. > How do you know that it worked? Maybe it worked only for the few people who > actually used it? Did it work in pkgcore and paludis? I have FEATURES=test in make.conf since 2010 year using only package.use.mask for disabling tests per package. It worked fine until this bug report. Do not use pkgcore or paludis. > Restricting tests per-arch is not a good idea. That usually means that someone > is masking failures and pretending that something does work properly. It was just example, possibly not the best. Actually i never masked tests per profile or arch, the only use case i had: mask broken tests without any condition. > > 3) Using package.use.mask is just simpler: creating file with custom env > > variables and then sourcing it via second file vs just masking one USE flag > > by adding one line to one file. > > How simpler? We're talking about creating one file in /etc/portage/env once and > using it in /etc/portage/package.env vs creating a local profile. When you open '/etc/portage/profile/package.use.mask' and see line 'foo/bar test', you sure know, that tests are disabled for package foo/bar When you open '/etc/portage/package.env' and see 'foo/bar notests.conf', you guess, that tests are disabled. But you do not know it for sure until you read '/etc/portage/env/test.conf' If you are dealing with your current desktop system, you remember what every custom .conf does, but if it is system, which you see first time or did not see for a while, you need to read these custom .conf files and check what and how exactly are they doing. (In reply to comment #13) > > > 3) Using package.use.mask is just simpler: creating file with custom env > > > variables and then sourcing it via second file vs just masking one USE flag > > > by adding one line to one file. > > > > How simpler? We're talking about creating one file in /etc/portage/env once and > > using it in /etc/portage/package.env vs creating a local profile. > > When you open '/etc/portage/profile/package.use.mask' and see line 'foo/bar > test', you sure know, that tests are disabled for package foo/bar No. When I see that, I say 'wtf?' Did someone just mask test dependencies? > When you open '/etc/portage/package.env' and see 'foo/bar notests.conf', you > guess, that tests are disabled. But you do not know it for sure until you > read '/etc/portage/env/test.conf' > If you are dealing with your current desktop system, you remember what every > custom .conf does, but if it is system, which you see first time or did not > see for a while, you need to read these custom .conf files and check what > and how exactly are they doing. Do you often work with systems where people intentionally put 'no-tests' files in order to do something else than disabling tests? (In reply to comment #8) > (In reply to comment #4) > > Zac, please explain, what is now correct way of masking tests per package in > > global (portage tree, overlays) and local profiles? Should masking with > > profile/package.use.mask be supported? > > You can use /etc/portage/package.env, like this: > > echo 'FEATURES="-test"' > /etc/portage/env/no_test.conf > echo 'dev-python/setuptools no_test.conf' >> /etc/portage/package.env Don't do that; fix the actual issue, the ability to disable tests via USE=-test has been around a *long* time- I know pkgcore has had it for years, and portage has had similar (minimally, look at bug #373209 fixing portage support yet again). > (In reply to comment #7) > > (In reply to comment #6) > > > > That was my thought as well. Maybe we should add "test" to IUSE_IMPLICIT in > > the base profile? > > Not sure if it's really necessary, give the above approach. PMS doesn't even discuss FEATURES, so adding test to IUSE_IMPLICIT still doesn't actually lock down the long standing behaviour; it would just fix portage for eapi5. Frankly, it's better to just recognize the history here and add the exception; if folks want to force it via IUSE_IMPLICT, fine, although that means each/every profile structure people build will have to carry all of those (which is kind of retarded). (In reply to comment #15) > Don't do that; fix the actual issue, the ability to disable tests via > USE=-test has been around a *long* time- I know pkgcore has had it for > years, and portage has had similar (minimally, look at bug #373209 fixing > portage support yet again). > > PMS doesn't even discuss FEATURES, so adding test to IUSE_IMPLICIT still > doesn't actually lock down the long standing behaviour; it would just fix > portage for eapi5. > > Frankly, it's better to just recognize the history here and add the > exception; if folks want to force it via IUSE_IMPLICT, fine, although that > means each/every profile structure people build will have to carry all of > those (which is kind of retarded). Then we'd have to retroactively amend PMS for EAPI 5. Re-assigning to pms-bugs, since there's nothing to do for portage unless we amend PMS. (In reply to comment #16) > (In reply to comment #15) > > Don't do that; fix the actual issue, the ability to disable tests via > > USE=-test has been around a *long* time- I know pkgcore has had it for > > years, and portage has had similar (minimally, look at bug #373209 fixing > > portage support yet again). > > > > PMS doesn't even discuss FEATURES, so adding test to IUSE_IMPLICIT still > > doesn't actually lock down the long standing behaviour; it would just fix > > portage for eapi5. > > > > Frankly, it's better to just recognize the history here and add the > > exception; if folks want to force it via IUSE_IMPLICT, fine, although that > > means each/every profile structure people build will have to carry all of > > those (which is kind of retarded). > > Then we'd have to retroactively amend PMS for EAPI 5. Re-assigning to > pms-bugs, since there's nothing to do for portage unless we amend PMS. In the interim, portage broke it's own behaviour. I'd fix that rather than play hot potatoe w/ PMS. :) Portage's EAPI 5 behavior is intentional, since it results from EAPI 5's implicit IUSE rules. I don't like the idea of using use.mask settings for things that aren't members of IUSE_EFFECTIVE. It just doesn't feel right. I think "test" became a special case when it was bound to FEATURES. If FEATURES="test" enables or disables tests for all packages, whether they have "test" in IUSE or not, it stands to reason that masking the flag to disable the feature would work likewise. The current behaviour is confusing and inconsistent (I've been wondering for weeks now why half my masks haven't been working). IIUC this bug isn't about the spec but about the implementation. Reassigning (keeping pms in CC). Ping. Looks like we won't revert to EAPI 4 behaviour, and I see no other suggestion for a change. So, can this bug be closed? Closing per comment #6 and comment #18. |
