From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 1CB61138010 for ; Sun, 2 Sep 2012 13:09:23 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AE424E04F2; Sun, 2 Sep 2012 13:09:08 +0000 (UTC) Received: from mo-p05-ob.rzone.de (mo-p05-ob.rzone.de [81.169.146.182]) by pigeon.gentoo.org (Postfix) with ESMTP id 79478E0175 for ; Sun, 2 Sep 2012 13:08:16 +0000 (UTC) X-RZG-AUTH: :IW0NeWCpcPchHrcnS4ebzBgQnKHTmUiSF2JlOcyz+57jTVMtVX7471ELeN8= X-RZG-CLASS-ID: mo05 Received: from pinacolada.localnet (95-130-166-116.hsi.glasfaser-ostbayern.de [95.130.166.116]) by smtp.strato.de (jorabe mo10) (RZmta 30.13 AUTH) with ESMTPA id 906a48o82Bv2Az for ; Sun, 2 Sep 2012 15:08:15 +0200 (CEST) From: "Andreas K. Huettel" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] EAPI usage Date: Sun, 2 Sep 2012 15:10:46 +0200 User-Agent: KMail/1.13.7 (Linux/3.3.1-gentoo; KDE/4.9.0; x86_64; ; ) References: <1650487.RNHkTcOSMI@elia> <201208311103.19398.dilfridge@gentoo.org> In-Reply-To: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1547770.vYsrFLvSCq"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201209021510.55447.dilfridge@gentoo.org> X-Archives-Salt: f5ca409d-79ff-481c-afdd-40743e871fb5 X-Archives-Hash: bb841ae839b9a1a905ef4df1bac623c3 --nextPart1547770.vYsrFLvSCq Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > [...] > > standards. So, we declare that gcc-4.5 has to be enough for everyone, > > we'll just keep it in tree forever and dont bother anymore with all > > these superfluous "does not build with gcc-4.7" bugs. >=20 > That is not an appropriate analogy, as I'm not suggesting that we > refuse to support newer EAPIs. I'm just saying that packages > shouldn't be bumped just for the sake of bumping them. Well I'm also not "suggesting" that we refuse to support newer gcc. Just, i= f a=20 package does not build with newer, meh, why care. Take old one. > I might see some benefit for devs who routinely modify stuff that they > don't maintain, but that should generally be kept to a minimum anyway. > If unsure how how to edit any particular ebuild, just file a bug! > And if the package isn't maintained, then nobody will be bumping its > EAPI anyway. True but... we do have some fluctuation, and developers come and go. Who ca= n=20 update the ebuild better, someone who has maintained it for a while and is= =20 familiar with its details and the current eapis, or someone who has just=20 picked up its pieces. What I dont actually understand at all is why bumping the EAPI should be so= =20 complicated or involved that it even deserves so much resistance...=20 OK there may be miraculous eclasses (or one in particular) which change api= =20 radically from eapi to eapi, but I think we've already decided long time ag= o=20 that this is a bad thing(tm) and should not be done. So let's hope it will = not=20 happen again.=20 Other than that, I can not remember any ebuild where the EAPI bump alone to= ok=20 me more than 5min. Now take the frequency of new eapi's coming out, and=20 compare it with the time that you need for a version bump of a package anyw= ay=20 (check upstream changelog, verify dependencies have not changed, do a test= =20 build, check for correct installation locations, ...) As an additional bonus this keeps your memory fresh about all the great new= =20 features... Cheers,=20 Andreas =2D-=20 Andreas K. Huettel Gentoo Linux developer=20 dilfridge@gentoo.org http://www.akhuettel.de/ --nextPart1547770.vYsrFLvSCq Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEABECAAYFAlBDWt8ACgkQ3ao2Zwy3NWqAFwCgkv2KYQxx3aeieKckjYxKjZMj kFkAnAsvR3RyxobnS7KGvktWiNxluIXE =0LJz -----END PGP SIGNATURE----- --nextPart1547770.vYsrFLvSCq--