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 ;-)
