Dnia 2013-08-15, o godz. 11:09:50 Tom Wijsman <tom...@gentoo.org> napisał(a):
> On Thu, 15 Aug 2013 10:10:02 +0200 > Pacho Ramos <pa...@gentoo.org> wrote: > > > El mié, 14-08-2013 a las 23:53 +0800, Patrick Lauer escribió: > > [...] > > > Well, it should reflect reality. > > > > > > PMS is still broken as much as it does not reflect the state of > > > portage before PMS was written, and we've had to patch it up a few > > > times to make it coherent, plus it is still lacking half the things > > > that would make it useful as a standard. > > > > > > Your academic interpretation of standard as a platonic ideal > > > disconnected from reality serves no purpose. > > > > > > > On this topic I agree with Patrick: I don't fully understand why > > things (like in_iuse from eutils.eclass) are missing from PMS. > > Why do things that can be in an eclass need to be in the PMS? > > Or more specifically, why would you like to see in_iuse in the PMS? in_iuse() is a cheap hack that does not confirm to the PMS. The problem is that PMS provided us with no way to query incremental variables like $IUSE. It makes the value of such variables 'undefined'. Which, shortly saying, means something like 'you can't query it'. Therefore, in_iuse() is broken and unsupported and you will be damned for using it. The only reason I added it to eutils.eclass was because people did it in even a more broken way. It's mostly like 'we know it's broken, so better keep it confined'. What future EAPI could do is to provide a legitimate way of querying it. Not that I really agree with doing that but it's not my call how people mis-design eclasses, and that's out-of-topic here. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
