Gentoo Archives: gentoo-portage-dev

From: Michael Lienhardt <michael.lienhardt@×××××××.net>
To: Ulrich Mueller <ulm@g.o>
Cc: gentoo-portage-dev@l.g.o, Zac Medico <zmedico@g.o>
Subject: Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?
Date: Wed, 17 Jun 2020 12:02:08
Message-Id: a4bf8f01-f58b-490d-bd1e-feafd332290e@laposte.net
In Reply to: Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies? by Ulrich Mueller
1 Le 17/06/2020 à 10:35, Ulrich Mueller a écrit :
2 >>>>>> On Wed, 17 Jun 2020, Michael Lienhardt wrote:
3 >
4 >> But maybe, "error" here in the PMS mean "the cpvs without the use flag
5 >> does not match that dependency and a warning should be raised to
6 >> improve compatibility in the future". In that case, it would be
7 >> clearer for me to change 'error' in the PMS into something like
8 >> "results in a no match,
9 >
10 > IMHO we cannot assume that. If the flag is not in the dependency's
11 > IUSE_EFFECTIVE then behaviour is undefined.
12
13 Fair enough.
14 However, currently the PMS says it is an error, not an undefined behavior.
15
16 >> but should be avoided". That way, it is explicitly stated that missing
17 >> use flags for a 2-style USE dependency is accepted (which is the
18 >> current behavior of emerge) but frown upon, without forcing any
19 >> specific error handling, like Michał accurately pointed out.
20 >
21 > The real problem is that we don't have a good procedure for removing
22 > flags from ebuilds with reverse (2-style) use dependencies. (And even
23 > with 4-style use dependencies the problem remains that one cannot know
24 > in advance whether removal of the flag implies that the feature is now
25 > unconditionally enabled, or that it is disabled.)
26
27 Indeed.
28 This is outside the scope of my original question, but intuitively, I
29 would imagine that the devs should know why they remove a use flag. It's
30 just an idea, but I see two possibilities.
31 1. either the change is temporary: in that case, they could keep the use
32 flag and set its value in REQUIRED_USE during that period
33 2. either the change is durable: in that case, it is still possible to
34 keep the use flag (while still setting its value in REQUIRED_USE) during
35 a period of time during which it is possible to update the dependencies
36 toward that package (the use flag would become deprecated before being
37 removed).
38 That way, enforcing the error described in the PMS would be telling to
39 the devs that they didn't update their dependencies during the
40 transition period.
41
42 Best,
43 Michael