Gentoo Archives: gentoo-dev

From: Johannes Huber <johu@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] EAPI usage
Date: Fri, 31 Aug 2012 09:34:51
Message-Id: 2734956.DPl8juOARd@elia
In Reply to: Re: [gentoo-dev] EAPI usage by "Andreas K. Huettel"
1 Am Freitag, 31. August 2012, 11:03:06 schrieb Andreas K. Huettel:
2 > Am Donnerstag, 30. August 2012, 12:57:25 schrieb Rich Freeman:
3 > > On Thu, Aug 30, 2012 at 6:28 AM, Johannes Huber <johu@g.o> wrote:
4 > > >> scarabeus suggested the change "dev should use latest eapi when
5 > > >> bumping"
6 > > >> to "dev must use latest eapi when bumping if not forbidden by
7 > > >> eclasses".
8 > > >> He was asked to bring it up on the mailing lists, to get a better
9 > > >> definition of when what EAPI should be used.
10 > > >
11 > > > I raised the issue through scarabeus, as in my opinion there is no
12 > > > reason
13 > > > to not use latest EAPI. So please discuss.
14 > >
15 > > I can't say I'm a big fan of this. This requires forcing changes to
16 > > ebuilds that offer no actual benefit to either the maintainer or the
17 > > end-users (changes that actually have some benefit to either are
18 > > likely to be made anyway). The PM maintainers have chimed in that
19 > > there is no benefit to PM maintenance from this change.
20 > >
21 > > So, I can't really see what the upside of such a policy is.
22 >
23 > <rant>
24 > Let's say, we as in Gentoo decide that we're completely sick of keeping all
25 > that old code out there adjusted to newer and newer gcc versions that are
26 > more and more critical towards minor details of the c++ standards. So, we
27 > declare that gcc-4.5 has to be enough for everyone, we'll just keep it in
28 > tree forever and dont bother anymore with all these superfluous "does not
29 > build with gcc-4.7" bugs.
30 >
31 > Well, newer gcc versions might have some very minor marginal advantages, but
32 > they require that we mess with code that has worked for ages. They require
33 > that we actually give some thought on the evolution of the language
34 > semantics or nag upstream, but we can't really be bothered with that
35 > because of limited time. Also, keeping gcc-4.5 will always (trivially) keep
36 > us backward compatibility... much more important than forward
37 > compatibility, should porting to a much never future version ever become
38 > necessary.
39 >
40 > For a real world analogy, serious quakes happen only once a century... why
41 > should we even bother with improving building codes? I mean, at some point
42 > in the future things will fall apart anyway. Better dont shake anything in
43 > between.
44 > </rant>
45 >
46 > Sorry but I could not really resist... please take it with a grain of salt.
47 > However, seriously, ...
48 >
49 > Give me one non-trivial ebuild where you can absolutely guarantee that a
50 > bump from EAPI=0 to EAPI=4 will not enable any improvements (in
51 > readability, failsafe behaviour and code size for example).
52 >
53 > Last point, if someday the tree contains ebuilds with 7-8 different EAPI's,
54 > we'll have succeeded in generating an unmaintainable mess (tm). It will not
55 > be any fun to look up things in PMS anew everytime you edit something. (Was
56 > the prayer to Paludis only required in EAPI=7 in src_prepare or in EAPI=8
57 > in pkg_preinst?) This problem could however also be solved by selectively
58 > phasing out in-between EAPIs (i.e. deprecate EAPIs 1 and 3 asap).
59
60 Words of wisdom, nothing to add.
61
62 Greetings.
63
64 > Cheers,
65 > Andreas
66
67 Cheers,
68 --
69 Johannes Huber (johu)
70 Gentoo Linux Developer / KDE Team
71 GPG Key ID F3CFD2BD