Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items, council meeting 8/October/2017 18:00 UTC

[Ulrich Mueller <ulm@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]

>>>>> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]