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 994FA138010 for ; Thu, 18 Oct 2012 15:49:49 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 93658E01BE; Thu, 18 Oct 2012 15:49:40 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 15902E00B5 for ; Thu, 18 Oct 2012 15:49:07 +0000 (UTC) Received: from [192.168.1.33] (230.Red-2-137-43.dynamicIP.rima-tde.net [2.137.43.230]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pacho) by smtp.gentoo.org (Postfix) with ESMTPSA id ADCA733D80C for ; Thu, 18 Oct 2012 15:49:05 +0000 (UTC) Subject: Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages. From: Pacho Ramos To: gentoo-dev@lists.gentoo.org In-Reply-To: References: <20121012125315.33500bbb@sera-17.lan> <20121012211023.592e82a1@gentoo.org> <20121013082820.75d280a1@sera-17.lan> <20121016234230.3b79a2fe@gentoo.org> <1350495278.2447.33.camel@belkin4> <20121017220707.02c6f5ac@gentoo.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-xcYxtJKE/ENCbXileI+W" Date: Thu, 18 Oct 2012 17:49:01 +0200 Message-ID: <1350575341.2447.40.camel@belkin4> 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 X-Mailer: Evolution 2.32.3 X-Archives-Salt: 9b862f37-448d-4f12-9019-eb218a7be21b X-Archives-Hash: 9cc633005a261c313c84da702fd6497f --=-xcYxtJKE/ENCbXileI+W Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable El jue, 18-10-2012 a las 09:36 -0400, Rich Freeman escribi=C3=B3: > On Thu, Oct 18, 2012 at 12:07 AM, Ryan Hill wrote: > > On Wed, 17 Oct 2012 15:00:12 -0400 > > Rich Freeman wrote: > >> I think the whole developers-can't-handle-47-EAPIs thing is a red > >> herring. The fact that there are packages written in Erlang in the > >> tree doesn't cause me any issues even though I haven't had to do any > >> work in Erlang. If I ever wanted to maintain such a package then I'd > >> take the time to learn it as needed. Likewise, if I wanted to > >> maintain a package that used EAPI joe and I really prefer to work in > >> EAPI fred, then I'd revise it at my next convenience. > > > > Well, it's not just about ebuilds you maintain. Think about something > > like the gcc-porting trackers where you have to touch a lot of ebuilds > > across the tree. You really do have to have a working knowledge of the > > differences between EAPIs to do so. My browser bookmark to the EAPI > > cheatsheet is one of the more frequently used as it is. >=20 > Can't you just ask the maintainers to fix their ebuilds? And if they > don't respond or at least cooperate, well, then treeclean them. I > don't think that library maintainers should have to bend over > backwards to fix reverse dependencies, within reason. If out of the > whole tree two packages are blocking an upgrade, give a deadline or > treeclean them. If we have 47 bazillion packages that don't work on > the newer lib, then slot it and bug upstream. >=20 > I do agree that trying to auto-mangle ebuilds from 47 different EAPIs > doesn't make sense. Just assign a bug to the maintainer saying "do > this to your ebuild, or get it on EAPI foo so that I can fix it, by > or it is gone." The deadline is important - I've seen a > pattern on -dev where bugs linger without deadlines for months, and > then a deadline of two days is imposed, and then a big flame war > breaks out. Just set a deadline up-front and make it reasonable. >=20 > Rich >=20 >=20 I didn't think eapi4 features were still "unfamiliar" to so many people... let's say, what about deprecating eapi1, 2 and 0 for newer ebuilds? Is eapi2 so unfamiliar also to not force it as older eapi for newer ebuilds (eapi3 changes look to be minor when compared with eapi2) ? --=-xcYxtJKE/ENCbXileI+W 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) iEYEABECAAYFAlCAJO0ACgkQCaWpQKGI+9RXcgCgg/xSk56r1saNKS+uZMU+L7A3 +MoAnR2ugYzhVXpC2stsbHVwbpyeVMgn =0USj -----END PGP SIGNATURE----- --=-xcYxtJKE/ENCbXileI+W--