| 1 |
On Sunday 07 June 2009 11:34:12 Ulrich Mueller wrote: |
| 2 |
> >>>>> On Sun, 07 Jun 2009, Steven J Long wrote: |
| 3 |
> > |
| 4 |
> > I'd just like to know what the implications would be for users if we |
| 5 |
> > kept the .ebuild extension, and a new PMS were rolled out stating |
| 6 |
> > that the mangler were allowed to find the EAPI without sourcing (and |
| 7 |
> > giving the restrictions) once portage 2.2 was stable, or the ability |
| 8 |
> > to handle this backported to 2.1.6, and issued in a release? |
| 9 |
> |
| 10 |
> Even if we do only a one-time change of the file extension, can we |
| 11 |
> ever get rid of the old extension? Or are we then stuck with two |
| 12 |
> extensions in the tree until the end of time? |
| 13 |
> |
| 14 |
> Let's assume for the moment that we change from ".ebuild" to ".eb". |
| 15 |
> Then we obviously cannot change all ebuilds in the tree to ".eb", |
| 16 |
> otherwise old Portage versions would see an empty tree and there would |
| 17 |
> be no upgrade path. |
| 18 |
> |
| 19 |
> Or am I missing something? |
| 20 |
|
| 21 |
I come to the same conclusion. |
| 22 |
|
| 23 |
Which means that the easiest way to get things migrated will be a one-time |
| 24 |
change of the _sync_ location so that users have a chance to get to an |
| 25 |
upgrade-ready state on their system, then change sync location, then upgrade |
| 26 |
to the current state. |
| 27 |
|
| 28 |
In which case we actually do not have to change the file name anymore ... |
| 29 |
|
| 30 |
Of course things aren't always that easy, but if you add a "generation file" |
| 31 |
somewhere in the rsync checkout it is easy to see if your current rsync |
| 32 |
location is "old and deprecated" or "new and improved". And if you really |
| 33 |
absolutely have to do that you can change the sync location on every |
| 34 |
disruptive change, but (imo) that should be avoided. Less disruptive changes |
| 35 |
is better :) |
| 36 |
|
| 37 |
hth, |
| 38 |
|
| 39 |
Patrick |
Archives