1 |
On Wed, Jun 20, 2012 at 10:25 PM, Richard Yao <ryao@g.o> wrote: |
2 |
> Here is my wishlist for EAPI 5: |
3 |
> |
4 |
> Multilib (and/or multiarch) support |
5 |
> Automated epatch_user support |
6 |
> Parallel make checks |
7 |
> POSIX Shell compliance |
8 |
> |
9 |
> Here are some explanations: |
10 |
> |
11 |
> Multilib (and/or multiarch) support |
12 |
> The current binaries cause a great deal of pain, particularly when a |
13 |
> user does not want to upgrade something. I had this problem with WINE |
14 |
> and glibc because I wanted to avoid the reverse memcpy() fiasco on my |
15 |
> systems. This situation would have been avoided entirely if the package |
16 |
> manager supported multilib. |
17 |
> |
18 |
> Automated epatch_user support |
19 |
> Users should be able to test patches without modifying their ebuilds. |
20 |
> This also saves developer time because we don't need to navigate the |
21 |
> portage tree (or an overlay), make a change and test it. We could just |
22 |
> dump the patch in the appropriate directory and build. |
23 |
> |
24 |
> Parallel make checks |
25 |
> As it stands, `make check` is so slow that few people actually run it |
26 |
> and QA suffers as a result. We have the ability to do parallel checks, |
27 |
> but we need to explicitly put `emake check` into the ebuild and use |
28 |
> autoconf 1.12 to get that. It would be best if this behavior were the |
29 |
> default, not the exception. |
30 |
> |
31 |
> POSIX Shell compliance |
32 |
> There has been a great deal of work done to give the user full control |
33 |
> of what is on his system and there is more that we can do there. In |
34 |
> particular, I think a lean Gentoo Linux system should be able to use |
35 |
> busybox sh and nothing else. That requires POSIX shell compliance. |
36 |
> OpenRC init scripts support this and the configure scripts support this. |
37 |
> The few exceptions are bugs that are addressed by the Gentoo BSD developers. |
38 |
> As such, I think we should make EAPI=5 use POSIX shell by default. If |
39 |
> an ebuild requires bash, we can allow the ebuild to declare that (e.g. |
40 |
> WANT_SH=bash), but that should be the exception and not the rule. |
41 |
> |
42 |
|
43 |
Our ebuilds are written in bash. I dunno about you, but bash sucks for |
44 |
writing anything remotely complicated in. My goal is any script that |
45 |
is 200 lines of bash or more gets rewritten in something else (usually |
46 |
python.) I mean the canonical example here is the old python.eclass |
47 |
which was a masterful example of how bash can really be used to shoot |
48 |
yourself in the foot. |
49 |
|
50 |
However I'd argue that the opposite of what Ciaran said is true. Screw |
51 |
trying to get the PM to stop using bash; developers are not interested |
52 |
in writing ebuilds in posix shell; bar none. |
53 |
|
54 |
Why would I as an ebuild author waste a bunch of time writing my |
55 |
ebuild in posix compatible sh when I can use bash (and if I had a |
56 |
better language than bash to write ebuilds in; I'd use that too.) You |
57 |
are free to write your ebuilds in posix sh; good luck to you. |
58 |
|
59 |
-A |