From ce8a77c858c679f2d7627a3cd613436b2ead82e7 Mon Sep 17 00:00:00 2001 From: Juan Manuel Palacios Date: Fri, 12 Dec 2008 03:11:11 +0000 Subject: [PATCH] Revert part of https://trac.macports.org/changeset/43375, as my understanding of the floating point to x.y.z transition was indeed a bit flawed. @MP_VERSION@ and base/config/mp_version being in the old floating point format, and @MACPORTS_VERSION@ and base/config/macports_version being their x.y.z counterparts, the correct analysis goes as follows: 1. 1.700 and previous clients need to read the floating point version number in newer releases, as otherwise they'll be comparing, e.g., 1.700 vs. 1.8.0, which will fail to trigger any upgrade. Therefore, revive the base/config/mp_version file for it to exist in svn && rsync, which is all that's needed to get selfupdate working for old clients again (given that they prefer that file over config/base/macports_version). 2. Remove the special-case hack in macports::selfupdate, since base/config/mp_version @ 1.800 is enough to upgrade all 1.700 and previous clients to 1.8.x, while those in turn have no need for the hack at all (they'll only read base/config/macports_version while selfupdating and thus rpm-vercomp its contents successfully against their internal version number, i.e. @MACPORTS_VERSION@). 3. Proposal: freeze base/config/mp_version @ 1.800, since point 1 above takes care of all pre 1.8.0 clients across the transition and point 2 of all post 1.8.0 clients going forward (they record @MACPORTS_VERSION@, rather than @MP_VERSION@, as their version number and compare that against base/config/macports_version when selfupdating, so there will be no need to update base/config/mp_version beyond anything greater than the last floating point release, i.e. 1.700). So, from this analysis I conclude that the only thing necessary to get pre 1.8.0 clients across to 1.8.x, added to what was done up until https://trac.macports.org/changeset/43375, is the existence of base/config/mp_version in svn, and as soon as we remove it we break selfupdate backwards compatibility with them, at which point we'll need to instruct stragglers to either force the selfupdate or install from the dmg. PS: I've thought all this out rather extensively, so I believe this approach is functional, but don't be shy to pull my ear if I again got it wrong! git-svn-id: https://svn.macports.org/repository/macports/trunk/base@43571 d073be05-634f-4543-b044-5fe20cf6d1d6 --- config/mp_version | 1 + src/macports1.0/macports.tcl | 8 -------- 2 files changed, 1 insertion(+), 8 deletions(-) create mode 100644 config/mp_version diff --git a/config/mp_version b/config/mp_version new file mode 100644 index 000000000..ccdd4f859 --- /dev/null +++ b/config/mp_version @@ -0,0 +1 @@ +1.800 diff --git a/src/macports1.0/macports.tcl b/src/macports1.0/macports.tcl index 19c54a4ed..5412f19a5 100644 --- a/src/macports1.0/macports.tcl +++ b/src/macports1.0/macports.tcl @@ -1878,14 +1878,6 @@ proc macports::selfupdate {{optionslist {}}} { set macports_version_new 0 } - # Temporary special-case hack to move MacPorts away from floating point version numbers: - # If we encounter a floating point version number smaller or equal to 1.800, we force the - # upgrade, since the 8 in 1.8.x will always be smaller than, e.g. the 700 in 1.700, the 610 - # in 1.610, etc, and therefore the upgrade would never trigger on its own. - if {$macports::autoconf::macports_version <= 1.800} { - set use_the_force_luke yes - } - # check if we we need to rebuild base if {$use_the_force_luke == "yes" || [rpm-vercomp $macports_version_new $macports::autoconf::macports_version] > 0} { if {[info exists options(ports_selfupdate_pretend)] && $options(ports_selfupdate_pretend) == "yes"} {