From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1J602n-00026j-E3 for garchives@archives.gentoo.org; Sat, 22 Dec 2007 08:49:17 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.2/8.14.0) with SMTP id lBM8ljDu018188; Sat, 22 Dec 2007 08:47:45 GMT Received: from sitar.i-cable.com (sitar.i-cable.com [203.83.115.100]) by robin.gentoo.org (8.14.2/8.14.0) with SMTP id lBM8ja24015644 for ; Sat, 22 Dec 2007 08:45:37 GMT Received: (qmail 7712 invoked by uid 508); 22 Dec 2007 08:45:35 -0000 Received: from 203.83.114.122 by sitar (envelope-from , uid 505) with qmail-scanner-1.25 (clamdscan: 0.90.3/4349. Clear:RC:1(203.83.114.122):. Processed in 0.116896 secs); 22 Dec 2007 08:45:35 -0000 Received: from ip114122.hkicable.com (HELO xenon.i-cable.com) (203.83.114.122) by 0 with SMTP; 22 Dec 2007 08:45:34 -0000 Received: from [192.168.1.100] (cm222-167-208-85.hkcable.com.hk [222.167.208.85]) by xenon.i-cable.com (8.13.5/8.13.5) with ESMTP id lBM8jYTR006154 for ; Sat, 22 Dec 2007 16:45:34 +0800 (CST) Message-ID: <476CCF39.3080708@gentoo.org> Date: Sat, 22 Dec 2007 16:47:53 +0800 From: Zhang Le User-Agent: Thunderbird 2.0.0.9 (X11/20071123) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) References: <200712172320.01988.peper@gentoo.org> <20071221040215.481ea7e0@blueyonder.co.uk> <476B401C.3000008@gentoo.org> <200712211631.13264.bo.andresen@zlin.dk> In-Reply-To: <200712211631.13264.bo.andresen@zlin.dk> X-Enigmail-Version: 0.95.5 OpenPGP: id=1E4E2973 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by robin.gentoo.org id lBM8ljFc018188 X-Archives-Salt: c1100300-5e02-442d-8a63-c583bd0e7074 X-Archives-Hash: 2e659c37b5968114407bcb857d75f8bd Bo =D8rsted Andresen wrote: > On Friday 21 December 2007 05:25:00 Zhang Le wrote: >> The question is really simple. >> Whether we should have two different place to define EAPI? >=20 > We need two places because it wasn't implemented properly in the first = place=20 > and we want to retain backwards compatibility for people who use old ve= rsions=20 > of portage. The whole point is to keep a sane upgrade path available=20 > indefinitely for people with old versions of portage. Thanks, now I understand this. However, in the first draft the majority part of the glep talks about how= to decide EAPI value, which could make others misunderstand the real point b= ehind it. It should be made more clear in the first place, fortunately peper ha= s done that in the new draft of glep-55. BTW, thanks to peper for drafting this glep! However, this doesn't mean I have wholehearted accept this glep. This jus= t means if we ever decided we need ".ebuild-1" suffix, then surely we need = such an agreement on how to decide EAPI value. >=20 >> Proponents are trying to prove that we should at least need it be in f= ile >> name. >=20 > We need the file name to change because otherwise old versions of porta= ge will=20 > try to source the ebuild when the EAPI is unknown. This either blocks n= ew=20 > useful features that will make old versions of portage fail to source t= hem or=20 > results in more bug reports with zillions of dupes (like the bugs in [1= ])=20 > because people with ancient versions of portage feel the need to report= bug=20 > reports when portage fails after a sync. I think we can educate our user about what is really going on and how to = sovle this problem (upgrade PM), by GWN/NEWs on front page/IRC topics/Forums st= ick threads and so no. > At the very least it means waiting for a year between a release with a = version=20 > of portage that supports this and an EAPI that takes advantage of it. S= o now=20 > that leaves the question whether we want to change the file name once a= nd=20 > hope that we won't need to do it again or whether we want to use the=20 > technically more flexible way where the file name changes whenever a ne= w EAPI=20 > gets agreed upon. This is another thing needed to be sorted out before we decide to take th= is suffix approach. >=20 > Or alternatively whether we want to limit ourselves by using an inferio= r=20 > solution that limits or delays progress considerably and results in mor= e bug=20 > reports with zillions of dupes... Honestly I really don't think our progress would be delayed in any way. T= he argument to which other approach would delay our progress is that we need= to wait people to upgrade their PM. (If this assertion is wrong please ignor= e th e following sentence) But upgrading PM is very easy, we can use all the channels we have to inform user to upgrade their PM. And people are thems= elves doing this all the time. BTW, if we decide to use .ebuild-1, will we provide a ebuild file for eac= h EAPI for a specific version of software? I guess probably not, coz that is a huge waste of time and energy. If thi= s is the case, then presumably we only provide new EAPI ebuild for new version= s. If a user want to use the new version, he *has* to upgrade his PM so that= it could support the new EAPI. --=20 Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 --=20 gentoo-dev@gentoo.org mailing list