On Sun, 17 Nov 2013 19:10:21 +0000 (UTC) Martin Vaeth wrote: > Tom Wijsman wrote: > > Martin Vaeth 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