Dnia 2013-08-15, o godz. 10:04:47 Pacho Ramos <pa...@gentoo.org> napisał(a):
> El jue, 15-08-2013 a las 07:42 +0800, Patrick Lauer escribió: > > I'm quite surprised that you attack hasufell now for his valid opinion > > that PMS is not well maintained and does not reflect reality adequately. > > > > Wouldn't be much easy to try to get sets support approved for the next > eapi? (eapi6 I think). Once we get the usual problems, we can complain > but, who knows, maybe (as it's already implemented in a PM) it doesn't > take so long to get approved (or maybe I am being too optimistic :( ) But what for? So far there is a lot of noise but I don't think anybody really decided what he wants from the PMS. Sets are wide and dynamic feature in portage, and it can't go straight to PMS. We need to choose a subset of sets to support, and then define it. But what subset do people really want? Open a separate thread, preferably on gentoo-pms, and start harvesting data. Crystal balls won't work in Gentoo. > > (not well maintained: simple patches take months to get applied, and > > even then often need council interference to be applied. Does not > > reflect reality: Multiple cases like mandating bash 3.2 that we don't > > even have in tree anymore, so no compliance testing possible. > > Maybe a quick new eapi bump (5.1?) including this and other small > changes that are quick to implement could help :/ Please not. We have enough mess with all the current EAPIs, sub-EAPIs are only going to make it worse. Also, please remember that adding bash-4 in a new EAPI is far from a helpful solution. The main source of complex bash code are eclasses. If you want bash-4 in the eclasses, you can't rely on it while the eclass supports older EAPIs. So you end up using conditionals, and I really prefer ${BASH_VERSINFO[@]} check for this over $EAPI checks. So, yes, get it for EAPI 6 and near EAPI 7 or 8 we may have first *new* eclasses that could be able to be pure-bash4 (see python-r1 problems). But EAPI 5.1 sounds like a tiny creep that isn't going to do much except for giving us more work to support it. > > Not > > documenting package.mask as a directory for EAPI0 even when that feature > > existed in portage before the initial release of PMS. Etc. etc.) > > > > I wasn't aware of this issue at all, does it have a bug report tracking > it? (for knowing its status, why it is being ignored or bringing the > problem to the council if needed) Please take care that not all people > are aware of the PMS related issues :) And when was it used in the ebuild tree? You shouldn't really expect people to document hidden features of portage that weren't really used at the time. And I still don't see a real reason to have those in gx86. This sounds like a good way to make committing to profiles even messier than it was. -- Best regards, Michał Górny
signature.asc
Description: PGP signature