On Sunday 07 June 2009 11:34:12 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?
I come to the same conclusion. Which means that the easiest way to get things migrated will be a one-time change of the _sync_ location so that users have a chance to get to an upgrade-ready state on their system, then change sync location, then upgrade to the current state. In which case we actually do not have to change the file name anymore ... Of course things aren't always that easy, but if you add a "generation file" somewhere in the rsync checkout it is easy to see if your current rsync location is "old and deprecated" or "new and improved". And if you really absolutely have to do that you can change the sync location on every disruptive change, but (imo) that should be avoided. Less disruptive changes is better :) hth, Patrick
