One of the common points of pain with portage is the constant need to manually (or via autounmask) escalate USE flags required by packages to "As an end user, I want this". This is very sub-optimal, because for the most part: - If I want to install package X - And package X requires package Y with USE="bar" Then I don't really actually *care* if Y has 'bar' or not, its something X cares about, not me. Subsequently, I've often wished there was a way to discriminate these situations via configuration. As a scratch concept, imagine if package.use supported 4 states: a. USE flag mandatory ( +!foo ) b. USE flag requested, but not mandatory ( +~foo ) c. USE flag unwanted, but not mandatorially ( -~foo ) d. USE flag forbidden ( -!foo ) states "a" and "d" here represent the current two options we have at our disposal. Stats "b" and "c" are advisory, meaning they default to "on" or "off" respectively, but with an important distinction: - Portage is free to internally toggle those flags as-needed without any changes to user configuration. I'd be inclined to employ this feature for things like PYTHON_TARGETS, and I'd be specifying _every_ python_target as "unwanted by default" ( Because I'm not doing python development myself, and I couldn't care how its built ), and then portage would be permitted to turn on each target as it deemed necessary. This would be much better than our current two options: 1. Set PYTHON_TARGETS globally to avoid pain, at the cost of having literally everything built for every specified PYTHON_TARGET ( and potentially expanding the graph to support this ), despite the fact one might have _nothing_ that needs it. 2. Set PYTHON_TARGETS globally to a more restricted set, and then piecewise hack it together with thousands of package.use declarations, marshalled by --autounmask, ... which, after adding, live in effective perpetuity, long beyond the period where they're actually needed. ( Try cleaning that up, you'll be sorry you did ) Instead, this half-option would allow portage to only turn on the targets as needed to support things the user actually wants and needs, which, as a result, enables portage to *automatically* strip installed support for older python targets as soon as nothing in the graph requires them, in a sort of "reference-counting garbage collection" fashion. The same axioms apply to ABI_X86="32" when you're running a 64 bit processor. I really don't want 32 bit support for everything in existence, I just want it for the "end goals" that necessitate it. But as it stands, I'm *required* to care about these in a finely grained detail, and risk having portage conflate "something needs" with "I need", which is false. ( I really do not need 32bit support for everything on my system simply because I have wine installed ) IMO, the configuration I declare in /etc/portage should communicate what I want, and _only_ what I want, not some extracted unification of what *packages* want. The *upside* of this strategy is also it gives portage more levity to solve conflicts, as instead of having to chase each USE flag as being a hard requirement, and begging the user to change them when it doesn't work out, it can solve the conflict on its own, because the user has already granted portage *permission* to do just that. And with this, portage gains the authority to break more cycles temporarily, because if a user doesn't care if a flag is on or off in a definite manner, portage is free to say "ok, you want that flag on, but I can't solve the graph with it on", and instead, build the graph with the flag off, and then, if it works, flip the flag back on and build it a second time. This is related to my other request: https://bugs.gentoo.org/697914 , in that, the mechanisms to make this work in portage are by necessity shared. If *that* bug can be implemented, then so can this. All we have left is the bike shed about the syntax for declaring them. And the end result is less begging from portage to flip flags ( which it presents as the only solution anyway ), and more portage Just Doing the things it knows works.
