Summary: | [Future EAPI] 'Prefer leftmost' implicit variant for REQUIRED_USE | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
Component: | Current packages | Assignee: | PMS/EAPI <pms> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | esigra, pacho |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=609338 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 174380 |
Description
Michał Górny
2017-02-14 13:17:52 UTC
I'd rather drop REQUIRED_USE in the next EAPI than complicate it further. (In reply to Ulrich Müller from comment #1) > I'd rather drop REQUIRED_USE in the next EAPI than complicate it further. Why not drop USE dependencies as well? If you're so much into making them useless. USE dependencies mostly work. REQUIRED_USE has completely failed at the simple task it was designed (and never tested before being shoved in at the last minute) for, and there's a perfectly good mechanism already available which doesn't have its problems. Some people are very happy with REQUIRED_USE, and others are not so happy. For those that want to drop it from the next EAPI, I think it would be worthwhile to do conduct a poll of gentoo developer opinions on the subject. What I find problematic with this proposal (as well as the one in bug 609338) is that it reuses the REQUIRED_USE variable for a purpose that is the opposite of what we have now. Currently the spec says: "If the package manager encounters a package version where REQUIRED_USE assertions are not met, it must treat this package version as if it was masked." Whereas what is sought here is a method to resolve such unmet assertions by switching some of the flags for the ebuild in question. So maybe it would be cleaner not to squeeze this into the existing REQUIRED_USE syntax, but (for example) introduce a new DEPEND style variable for it? (The wider scope of this is of course that if there are n USE flags and m valid package configurations, then often one will find that m < 2**n.) Let's abandon this in favor of GLEP73 (which implies prefer-leftmost behavior anyway). |