From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LbM81-0005bb-9r for garchives@archives.gentoo.org; Sun, 22 Feb 2009 21:44:49 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 46CFFE03A3; Sun, 22 Feb 2009 21:44:48 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 20287E03A3 for ; Sun, 22 Feb 2009 21:44:48 +0000 (UTC) Received: from arcarius.localnet (unknown [88.103.16.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 98A2BB5640 for ; Sun, 22 Feb 2009 21:44:47 +0000 (UTC) From: =?utf-8?q?Tom=C3=A1=C5=A1_Chv=C3=A1tal?= To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Suggestion for next bugday: Mass use deps migration Date: Sun, 22 Feb 2009 22:43:26 +0100 User-Agent: KMail/1.11.0 (Linux/2.6.28-gentoo-r2; KDE/4.2.0; x86_64; ; ) References: <499EE087.1030802@gentoo.org> <200902222234.25275.carlo@gentoo.org> In-Reply-To: <200902222234.25275.carlo@gentoo.org> 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="nextPart5329805.fbWu2gMzGA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200902222243.30071.scarabeus@gentoo.org> X-Archives-Salt: 77f88f05-6514-45d9-9b93-8afcaf87709f X-Archives-Hash: 41a539c02b5343085d69aeb73b08a566 --nextPart5329805.fbWu2gMzGA Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dne ned=C4=9Ble 22 =C3=9Anor 2009 22:34:19 > Carsten Lohrke wrote: > On Freitag, 20. Februar 2009, Petteri R=C3=A4ty wrote: > > Suggestions/objections? > > If you mean by "mass migration" doing that more or less blindly, I do > object. When an ebuild directly or indirectly inherits an eclass, which is > EAPI 2 enabled, like base.eclass, while another isn't, you have to expect > side-effects. See for example media-tv/kdetv-0.8.9-r1, which features an > empty src_prepare to prevent the attempt to apply patches twice, > temporarily. > > So the first step is to get all eclasses EAPI 2 ready and even then I > wouldn't rule out odd cases, so changes should happen in testing and > revised ebuilds exclusively to assure odd cases get caught. > > > Carsten Well that is the reason why i am first eapi2ing the kde eclass. I was reall= y=20 suprised when i saw kde3 ebuilds with eapi2 :( The smalest problems i can spot in the first place are: 1) not working PATCHES array 2) double configure script run. So i agree that we have to doublecheck every eclass and eapi2fy them in fir= st=20 place. Tomas --nextPart5329805.fbWu2gMzGA Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEABECAAYFAkmhxwIACgkQHB6c3gNBRYdKfgCgww+FPdIqM5rmSUGWDk6GSr3b RfUAoKqWUUDkMKmA/JsNz0rvewdZobix =55Yk -----END PGP SIGNATURE----- --nextPart5329805.fbWu2gMzGA--