Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Tom Wijsman <TomWij@gentoo.org>]

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

On Sun, 17 Nov 2013 19:10:21 +0000 (UTC)
Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:

> Tom Wijsman <TomWij@gentoo.org> wrote:
> > Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:
> >>
> >> So keeping PMS is more important than usability?
> >
> > Being supported is more important than running into breakage.
> 
> What has a line in PMS

You can suggest such line change on the gentoo-pms mailing list;
when you do that, I can understand which change you try to refer to.

(Note that this translates to multiple changed lines in each PM)

> which has practically no influence

Specifications need to work on the theoretical side too; if it works in
practice for you, it can sill have practical implications on other
consumers. It is a dangerous assumption to think different.

> on anybody except for breaking user experience have to do
> with "being supported"?

Two sentences appear to be mixed here, do you suggest that the line
change "breaks user experience"? The PMS is what we agree to and what
we support, anything else that breaks follows something different than
the PMS and is outside the boundaries of its associated support.

> Does any developer's life change so bad that he cannot
> support it anymore if the package manager no longer gives
> misleading errors to the user?

Output of the package manager itself is outside the scope of the PMS.

> > Does support increase user experience? What about breakage?
> 
> Yeah, treating user-config files in a clearer way will break things
> horribly.

Changes indeed bring along bugs and breakage; which you need to take
into account when doing risk assessment, going for the advantages it
brings only works out if you consider whether disadvantages bug you.

> Better question: What about the breakages which the
> side effect of package.accept_keywords has just proven to cause?

What about replacing known breakages by unknown breakages?

> > Let's say I want to have PM support for bug #449094 and do bug
> > #472906.
> 
> You proved that you can find modifications of PMS which obviously
> can have bad side effects in certain situations. And so what?
> I am not going to kick your strawman.

Can you proof that your line change only has good side effects?

> > So, let's not rush this magic
> > eapi-5-kernel feature and do it properly as part of eapi-6 or later.
> 
> Sure, introducing a new feature can wait until the involved
> packages provide the new EAPI.
> But the dependency breakage of the side effect we are talking
> about will stay as long as at least one package in the dependency
> chain is not EAPI=6 or newer, i.e. "not rushing" in your term
> means waiting for ... 10 years? ... 20 years? ...forever?

It needs a clairvoyant to tell, PMS changes on their own take some time;
and even if we could get it done before the end of the month, consider
that the package managers are currently undermanned. If you want to see
a solution soon, changing the PMS does not feel like a the way to go.

> This is simply not an appropriate way how to deal with problem
> when they turn up in an already released EAPI. Especially not,
> if it is such a tiny issue which can be fixed by reformulating
> one or two lines just with having the side effects in mind
> (which had probably surprised everybody - including myself -
> in this consequence).

It will be discussed, rewritten, voted upon, added, then the EAPI gets a
new revision / release; after that, actively used Package managers need
to implement it (which is not necessarily a single line change),
releases need to be made for these Package managers as well, those
releases need to be stabilized; at this point, the Council needs to
declare the new version for use after which the Portage tree migrates
to it (assuming the EAPI change brings along other fixes as well).

It's a bit more involved than a reformulation, it takes time...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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