Le 17/06/2020 à 10:35, Ulrich Mueller a écrit :
On Wed, 17 Jun 2020, Michael Lienhardt wrote:
But maybe, "error" here in the PMS mean "the cpvs without the use flag
does not match that dependency and a warning should be raised to
improve compatibility in the future". In that case, it would be
clearer for me to change 'error' in the PMS into something like
"results in a no match,
IMHO we cannot assume that. If the flag is not in the dependency's
IUSE_EFFECTIVE then behaviour is undefined.
Fair enough.
However, currently the PMS says it is an error, not an undefined behavior.
but should be avoided". That way, it is explicitly stated that missing
use flags for a 2-style USE dependency is accepted (which is the
current behavior of emerge) but frown upon, without forcing any
specific error handling, like Michał accurately pointed out.
The real problem is that we don't have a good procedure for removing
flags from ebuilds with reverse (2-style) use dependencies. (And even
with 4-style use dependencies the problem remains that one cannot know
in advance whether removal of the flag implies that the feature is now
unconditionally enabled, or that it is disabled.)
Indeed.
This is outside the scope of my original question, but intuitively, I
would imagine that the devs should know why they remove a use flag. It's
just an idea, but I see two possibilities.
1. either the change is temporary: in that case, they could keep the use
flag and set its value in REQUIRED_USE during that period
2. either the change is durable: in that case, it is still possible to
keep the use flag (while still setting its value in REQUIRED_USE) during
a period of time during which it is possible to update the dependencies
toward that package (the use flag would become deprecated before being
removed).
That way, enforcing the error described in the PMS would be telling to
the devs that they didn't update their dependencies during the
transition period.
Best,
Michael
