Gentoo Archives: gentoo-project

From: Ulrich Mueller <ulm@g.o>
To: Rich Freeman <rich0@g.o>
Cc: Kristian Fiskerstrand <k_f@g.o>, gentoo-project <gentoo-project@l.g.o>, Gentoo Council <council@g.o>
Subject: Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items, council meeting 8/October/2017 18:00 UTC
Date: Tue, 03 Oct 2017 16:57:18
In Reply to: Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items, council meeting 8/October/2017 18:00 UTC by Rich Freeman
>>>>> On Tue, 3 Oct 2017, Rich Freeman wrote:
> If the behavior of portage doesn't match the specification in PMS that > is reason enough to change one or the other. The purpose of PMS is to > document how package managers are supposed to behave.
> You could:
> 1. Change portage to behave as PMS specifies. > 2. Change PMS to specify portage's behavior. > 3. Change PMS to make the behavior explicitly undefined.
> Sure, this might be a lower-priority bug but this seems like a valid > one. What is the point in having a specification if we don't actually > specify what we're doing?
I believe I am aware of the options. :-) The goal is indeed that PMS and Portage behaviour should match, which isn't the case since 2011. So the normal course of action would be to change Portage. There are two aspects that make me believe that changing PMS would be a better choice, though: First, the feature is of questionable usefulness and hasn't seen any use in the tree. And second, if we implement GLEP 73 (which is in the list for EAPI 7) we are likely to tighten the rules in any case. So if we go for your option 1 or 3 above, the spec (and package managers as well) will end up with EAPI dependent behaviour, for a feature that isn't used. The proposed retroactive change would avoid that, and for existing EAPIs there is no practical difference. Ulrich