On Mon, 16 Nov 2015 10:06:17 +0100 "Justin Lecher (jlec)" <j...@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 16/11/15 10:01, Alexis Ballier wrote: > > On Fri, 13 Nov 2015 23:53:05 +0000 (UTC) "Michał Górny" > > <mgo...@gentoo.org> wrote: > > > >> commit: ad4c142684afb096e8fff2937ae5c5c3385dd22e Author: > >> Michał Górny <mgorny <AT> gentoo <DOT> org> AuthorDate: Fri Nov > >> 13 18:46:33 2015 +0000 Commit: Michał Górny <mgorny <AT> > >> gentoo <DOT> org> CommitDate: Fri Nov 13 23:52:53 2015 +0000 > >> URL: > >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ad4c1426 > >> > >> autotools-{utils,multilib}.eclass: Ban for EAPI=6 > >> > >> Ban autotools-utils.eclass and dependant > >> autotools-multilib.eclass for EAPI=6 to avoid them being > >> accidentally enabled. The former eclass should be replaced with > >> inline code, the latter with multilib-minimal.eclass. > > > > > > Not that I particularly like those eclasses, but I seem to have > > missed the deprecation warnings for these. I hope you're planning > > in submitting patches "fixing" consumers... > > Probably the developers should fix their ebuilds when they bump to > EAPI=6. While I haven't looked at the change exactly, Michał announced > it as a EAPI >= 6 Ban. So no backwards breakages expected. Probably those that want to ban it should fix the(ir) tree so that developers have no pain in bumping to eapi6? While I agree we should move away from those eclasses, the "I decided to throw the crap at other developers with eapi6 without deprecation period" is a bit hard to grasp. Esp. when these eclasses were advertised as the way to go not so long ago...
