Re: [gentoo-dev] Sets in the tree

[Michał Górny]

Dnia 2013-08-15, o godz. 10:04:47
Pacho Ramos <pacho@g.o> 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