From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from <gentoo-dev+bounces-36509-garchives=archives.gentoo.org@lists.gentoo.org>) id 1MDeDK-0000K2-Mx for garchives@archives.gentoo.org; Mon, 08 Jun 2009 12:44:34 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 03217E02CD; Mon, 8 Jun 2009 12:44:33 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id B9C78E02CD for <gentoo-dev@lists.gentoo.org>; Mon, 8 Jun 2009 12:44:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 59F5E64C1B for <gentoo-dev@lists.gentoo.org>; Mon, 8 Jun 2009 12:44:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 required=5.5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S33EUEnygJyW for <gentoo-dev@lists.gentoo.org>; Mon, 8 Jun 2009 12:44:25 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id BC69365326 for <gentoo-dev@gentoo.org>; Mon, 8 Jun 2009 12:44:23 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MDeD5-0005Az-0Q for gentoo-dev@gentoo.org; Mon, 08 Jun 2009 12:44:19 +0000 Received: from 91.85.167.206 ([91.85.167.206]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <gentoo-dev@gentoo.org>; Mon, 08 Jun 2009 12:44:19 +0000 Received: from slong by 91.85.167.206 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <gentoo-dev@gentoo.org>; Mon, 08 Jun 2009 12:44:19 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steven J Long <slong@rathaus.eclipse.co.uk> Subject: [gentoo-dev] Re: Re: GLEP 55 Version 2 Date: Mon, 08 Jun 2009 13:42:44 +0100 Organization: Friendly-Coders Message-ID: <5204115.WX2jVEVibr@news.friendly-coders.info> References: <18987.35220.808040.666422@a1ihome1.kph.uni-mainz.de> <1244383925.3671.1@NeddySeagoon> Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 91.85.167.206 Sender: news <news@ger.gmane.org> X-Archives-Salt: 102c2a87-95ca-4b8d-963a-7e1f0ef04f39 X-Archives-Hash: 1d35ae832bbe94a7fccb3fae788df052 Roy Bamford wrote: > On 2009.06.07 10:34, Ulrich Mueller wrote: >> >>>>> On Sun, 07 Jun 2009, Steven J Long wrote: >> >> > I'd just like to know what the implications would be for users if >> we >> > kept the .ebuild extension, and a new PMS were rolled out stating >> > that the mangler were allowed to find the EAPI without sourcing >> (and >> > giving the restrictions) once portage 2.2 was stable, or the >> ability >> > to handle this backported to 2.1.6, and issued in a release? >> >> Even if we do only a one-time change of the file extension, can we >> ever get rid of the old extension? Or are we then stuck with two >> extensions in the tree until the end of time? >> >> Let's assume for the moment that we change from ".ebuild" to ".eb". >> Then we obviously cannot change all ebuilds in the tree to ".eb", >> otherwise old Portage versions would see an empty tree and there >> would >> be no upgrade path. >> >> Or am I missing something? >> Sounds about right > > First, lets be clear that the upgrade path related problems are driven > by the EAPI change, not the .ebuild to .eb change. That serves only to > allow the new EAPI to be introduced immedately and hide the change from > older package managers > <snip> > To keep an upgrade path, package managers and their dependencies need > to use EAPI 0, 1 or 2. (EAPI 3 is not yet out) How far back should the > upgrade path extend? > Well given that EAPI 3 is not out, and that bash-4 is not even stable (and if anyone thinks we can rely on bash-4 in the next 6 months, they didn't learn anything from bash-3 imo) this sounds like it's a fair distance away. From discussion with Harring, EAPIs were not meant to come out very often; iirc he said something like maybe once a year. I concur with Duncan on a year, as you know. I appreciate you feel it should be longer, and am happy to go with whatever the consensus is. > As you suggest, even with .ebuild to .eb change.its not a clean break > with the past but would happen over time, with ebuilds for new package > versions being migrated to the new format. For example we would > have > foo-2.1-r1.ebuild > foo-3.0.eb > portage-2.3.ebuild > portage-3.0.eb > yuck. > Portage-2.3 will understand the later EAPI but will itself, use only > EAPI, 0, 1 or 2. > Just to be clear: portage-2.2 and later will be fine with any EAPI, with no change to any ebuilds, nor any new extension being needed. The change can easily be backported to 2.1.6, tho I suspect 2.2 will be stable fairly soon. > Thats just portage. The same reasoning applies to any other package > manager and there are at least three. This begs the question of how > friendly do we want to be to derivitive distros that use our tree but > their own package manager? > As friendly as we can be without hobbling our own development. Most of them appear to be fairly collaborative with Gentoo in any case. > Upgrade path issues need to be addressed in the GLEP. I will add > something like the above in the next version. > Wrt transitioning, can the eapi (PMS 5.2.2) and deprecated (5.2.3) files not be of use? I seem to recall the change from 2007.1 to 2008.0 for example; anyone using a deprecated profile can expect a massive warning the next time they try to do anything after sync'ing. Thanks again for your work; I appreciate that your time is valuable. Regards, Steve. -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)