Summary: | sys-apps/portage: map underscores to hyphens in USE flag names if the package has only the latter | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Michał Górny <mgorny> |
Component: | Core - Configuration | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | ulm |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=695172 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Michał Górny
2019-09-27 17:58:49 UTC
This should be doable in the config regenerate method. It can handle mappings for negative settings there as well. Perhaps it can generate mappings from IUSE simply by replacing all hyphens with underscores. Hopefully this kind of mapping could work to unambiguously map python_targets_python3_7 to python_targets_python3-7, yes? Can you think of any scenarios where this sort of mapping would lead to ambiguity? IIUC this would only cause problems if we had colliding IUSE values like 'foo_bar' and 'foo-bar'. I can't think of a real case for this. If we have USE_EXPAND="FOO" and a legitimate USE flag named foo-bar, then mapping foo_bar to foo-bar can cause problems only if foo_bar and foo-bar are both in the set of effective IUSE for the current package. Exactly. I don't think this really could happen. (In reply to Michał Górny from comment #2) > IIUC this would only cause problems if we had colliding IUSE values like > 'foo_bar' and 'foo-bar'. I can't think of a real case for this. So, currently foo_bar and foo-bar don't collide, but once the hack is in place, they will? Why do we bother with renaming flags, if the end result isn't a clear separation of namespaces? Can we at least limit this in time, and say that the hack will be removed again after a reasonable time for users to upgrade, say, one year? Worksforme. We could also apply update-like mechanism to update config files while at it. |