On Saturday 21 March 2009 22:26:41 Alec Warner wrote: > >> > > Introducing a policy encouraging moving things that definitely > >> > > aren't in the least bit likely to be a system dep on a bump, sure. > >> > > Making 1 or 2 the default for new packages, sure. But rewriting > >> > > existing things? That's just an accident waiting to happen. > >> > > >> > What kind of accident do you expect to happen? > >> > >> The same kind that always happens when lots of ebuilds get changed. > > > > ... lots of new features and a few bugs that get fixed the next day? Hey, > > that sounds quite bad. And maybe some new herd testers? How rude! > > I don't see the correlation between EAPI bumps and new herd testers.
Well, ciaran said that the same thing happens that always happens when lots of ebuilds get changed. Last time I saw that happen (think KDE4) we got some nice herd testers plus a new dev or two, so I am confused too. Maybe ciaran can explain what he meant to say so we don't have to come to unexpected conclusions (that would actually be a quite nice change to the average discussion - saying what you mean instead of hinting at star constellations and the importance of meat loaf) > > So what technical reason(s) do we have to keep archaic EAPIs around > > forever? > None, luckily this is more than a technical project ;) Stop confusing me, antarus, I thought you were against removing eapi0 and now you support the removal? ;) Anyway. Most of the "porting" effort (assuming no other issues sneaking in) would be adding a "EAPI=1" line to ebuilds, which could be done "lazily" on version bumps. There's no rush to get it killed now now now, but in a year we might be at EAPI 5, and then I don't want to be the one writing the docs that split apart what features are where and what syntax is valid and all that. So phasing out eapi0 would be an obvious step towards making things simpler for those of us that don't enjoy studying lists and tables ... Patrick
