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 ) id 1MDJ6W-0000At-Iz for garchives@archives.gentoo.org; Sun, 07 Jun 2009 14:12:08 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CAEBAE01CD; Sun, 7 Jun 2009 14:12:06 +0000 (UTC) Received: from smarthost03.mail.zen.net.uk (smarthost03.mail.zen.net.uk [212.23.3.142]) by pigeon.gentoo.org (Postfix) with ESMTP id 8E2DBE01CD for ; Sun, 7 Jun 2009 14:12:06 +0000 (UTC) Received: from [62.3.120.141] (helo=NeddySeagoon) by smarthost03.mail.zen.net.uk with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1MDJ6T-0000eu-Pd for gentoo-dev@lists.gentoo.org; Sun, 07 Jun 2009 14:12:05 +0000 Date: Sun, 07 Jun 2009 15:11:58 +0100 From: Roy Bamford Subject: Re: [gentoo-dev] Re: GLEP 55 Version 2 To: gentoo-dev@lists.gentoo.org In-Reply-To: <18987.35220.808040.666422@a1ihome1.kph.uni-mainz.de> X-Mailer: Balsa 2.4.0 Message-Id: <1244383925.3671.1@NeddySeagoon> 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: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Originating-Smarthost03-IP: [62.3.120.141] X-Archives-Salt: cbdffe0c-efd8-4691-8c8b-939cdbfb3b80 X-Archives-Hash: 7794a4f306764e136f0e96d7020ae18a -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2009.06.07 10:34, Ulrich Mueller wrote: > >>>>> On Sun, 07 Jun 2009, Steven J Long wrote: >=20 > > I'd just like to know what the implications would be for users if=20 > we > > kept the .ebuild extension, and a new PMS were rolled out stating > > that the mangler were allowed to find the EAPI without sourcing=20 > (and > > giving the restrictions) once portage 2.2 was stable, or the=20 > ability > > to handle this backported to 2.1.6, and issued in a release? >=20 > 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? >=20 > 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=20 > would > be no upgrade path. >=20 > Or am I missing something? >=20 > Ulrich First, lets be clear that the upgrade path related problems are driven=20 by the EAPI change, not the .ebuild to .eb change. That serves only to=20 allow the new EAPI to be introduced immedately and hide the change from=20 older package managers=20 The upgrade path issue remains even if we do the usual Gentoo introduce=20 new features to the package manager then wait a year or so before they=20 are deployed. Without the .ebuild to .eb change. late upgraders will=20 get the error messages in Appendix A of the GLEP when these features=20 are relesed.=20 To keep an upgrade path, package managers and their dependencies need=20 to use EAPI 0, 1 or 2. (EAPI 3 is not yet out) How far back should the=20 upgrade path extend? As you suggest, even with .ebuild to .eb change.its not a clean break=20 with the past but would happen over time, with ebuilds for new package=20 versions being migrated to the new format. For example we would=20 have=20 foo-2.1-r1.ebuild foo-3.0.eb portage-2.3.ebuild portage-3.0.eb Portage-2.3 will understand the later EAPI but will itself, use only=20 EAPI, 0, 1 or 2. =20 With the .ebuild to .eb change. users who do not upgrade portage will=20 not see newer versions of foo. Without it, they will get the error=20 messages in Appendix A of the GLEP. This will have the side effect of=20 driving the adoption of the newer package managers. It is not suffcient to have portage-2.3.ebuild as understanding later=20 EAPI files. All of its dependencies need to keep to EAPI 0, 1 or 2.=20 These must be the last packages to migrate to later EAPIs.=20 Thats just portage. The same reasoning applies to any other package=20 manager and there are at least three. This begs the question of how=20 friendly do we want to be to derivitive distros that use our tree but=20 their own package manager? Upgrade path issues need to be addressed in the GLEP. I will add=20 something like the above in the next version. - --=20 Regards, Roy Bamford (NeddySeagoon) a member of gentoo-ops forum-mods treecleaners trustees -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoryrUACgkQTE4/y7nJvashtQCgkO+feHG2BBGLOTObrwq72iOx nI4AoNZ67Mhq4yEKYTzfBOPmu98Py9Mc =3DGB62 -----END PGP SIGNATURE-----