Re: erroneous behavior in 2-style USE dependencies?

Michael Lienhardt <[email protected]>
Newsgroups gmane.linux.gentoo.portage.devel
Message-ID <[email protected]>

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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.