Gentoo Archives: gentoo-dev

From: Steven J Long <slong@××××××××××××××××××.uk>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: The fallacies of GLEP55
Date: Tue, 26 May 2009 14:02:56
Message-Id: 2944863.vOqsR3tN2Y@news.friendly-coders.info
In Reply to: [gentoo-dev] Re: The fallacies of GLEP55 by Duncan <1i5t5.duncan@cox.net>
1 Duncan wrote:
2
3 > Tobias Klausmann <klausman@g.o> posted
4 >> I was under the impression that it's illegal to change/set the EAPI
5 >> after using inherit.
6 >
7 > The short answer, based on my understanding of posts to this point, would
8 > be that it's illegal for Gentoo (in-tree, council decided), but not
9 > necessarily for all the overlays and Gentoo based projects out there.
10 >
11 > On the one hand, as a result of the above, Gentoo doesn't have to concern
12 > itself with the others and can decide what's best for the Gentoo tree and
13 > dev-sponsored overlays presumably targeted at eventual tree inclusion.
14 > On the other, regardless of what Gentoo decides, PMs wishing widest
15 > compatibility must be prepared for it anyway. If I'm not mistaken,
16 > paludis has the widest deployment footprint both in practice and by goal
17 > at this point, so naturally, those developing it have broader concerns
18 > than just Gentoo.
19 >
20 Well is it okay for the Gentoo developer list to be focussed firstly on
21 Gentoo product and solving the real issues people actually face as opposed
22 to non-issues like typing in a version specifier?
23
24 Further, if there is a valid use-case for setting EAPI after inherit, could
25 you (or someone else) explain what it is and why Gentoo, or indeed anyone
26 working on a Gentoo-based product, should care? ATM it looks like a classic
27 case of obfuscation; it's frankly well below par to post code that isn't
28 allowed and then claim it as a use-case requiring such massive changes.
29
30 I'd ask you also to consider prefix-portage when you assess the "deployment
31 footprint" (however you're coming to that conclusion.)
32 --
33 #friendly-coders -- We're friendly but we're not /that/ friendly ;-)