Gentoo Archives: gentoo-dev

From: Richard Yao <ryao@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: My wishlist for EAPI 5
Date: Thu, 21 Jun 2012 09:26:39
Message-Id: 4FE2E81B.5070107@gentoo.org
In Reply to: [gentoo-dev] Re: My wishlist for EAPI 5 by Duncan <1i5t5.duncan@cox.net>
1 On 06/21/2012 04:29 AM, Duncan wrote:
2 > Richard Yao posted on Wed, 20 Jun 2012 16:50:33 -0400 as excerpted:
3 >
4 >> On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
5 >>> On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao <ryao@g.o> wrote:
6 >>>> POSIX Shell compliance
7 >>> So far as I know, every PM relies heavily upon bash anyway (and can't
8 >>> easily be made not to), so even if developers would accept having to
9 >>> rewrite all their eclasses, it still wouldn't remove the dep.
10 >>>
11 >> Lets address POSIX compliance in the ebuilds first. Then we can deal
12 >> with the package managers.
13 > Additionally, this is extremely unlikely because a number of developers
14 > insist on bash, to the extent that it would likely split gentoo in half
15 > if this were to be forced. It wouldn't pass council. It's unlikely to
16 > even /get/ to council.
17 >
18 > Openrc could move to POSIX shell because its primary dev at the time
19 > wanted it that way and it's only a single package. However, even then,
20 > doing it was controversial enough that said developer ended up leaving
21 > gentoo in-part over that, tho he did continue to develop openrc as a
22 > gentoo hosted project for quite some years. Now you're talking trying to
23 > do it for /every/ (well, almost every) package, thus touching every
24 > single gentoo dev. It's just not going to happen in even the medium term
25 > (say for argument APIs 5-7ish), let alone be something practical enough
26 > to implement, soon enough (even if everyone agreed on the general idea,
27 > they don't), to be anything like conceivable for EAPI5.
28 >
29 > So just let that one be. It's simply not worth tilting at that windmill.
30 >
31 > (Arguably, multi-arch, while practical and actually working at least with
32 > portage in an overlay, fails that last bit as well. If it was pushed,
33 > perhaps for EAPI6 or 7, but it's just not practical to consider it for
34 > EAPI5... unless you want to wait 3-5 years for EAPI5!)
35 >
36 It is just a wish list.
37
38 Anyway, people need to decide on what they want from a new EAPI before
39 one is made. Once they decide, it should be possible to work out the
40 details.