On Dec 8, 2008, at 01:02, Juan Manuel Palacios wrote:
On Dec 7, 2008, at 5:27 PM, Juan Manuel Palacios wrote:
The way I see it (unless I'm brain dead at the moment and missing
something incredibly obvious, or completely misunderstanding the
way rpm-vercomp works), the real problem is in the contents of
both files:
-) mp_version contains 1.610 in the release_1_6 branch (what
regular uses currently have), 1.700 in the release_1_7 branch
(what will be released next);
-) macports_version contains 1.6.1 and 1.7.0, respectively;
-) in both 1.610 and 1.700, the necessity to rebuild base in a
selfupdate run is as follows;
from base/src/macprots1.0/macports.tcl:
if {$use_the_force_luke == "yes" || [rpm-vercomp
$macports_version_new $macports::autoconf::macports_version] > 0} {
and $macports::autoconf::macports_version comes from base/src/
macports1.0/macports_autoconf.tcl.in:
36 variable macports_version "@MP_VERSION@"
and @MP_VERSION@, in turn, is determined from base/config/
mp_version in base/configure.ac:
15 # Read the old, floating point format version, which we still
use internally, and export it for the
$macports::autoconf::macports_version variable
16 MP_VERSION=$(cat config/mp_version | tr -d '\n')
17 AC_SUBST(MP_VERSION)
So the real problem is determining when switching
$macports::autoconf::macports_version from @MP_VERSION@ to
@MACPORTS_VERSION@, the latter being determined from base/config/
macports_version, is appropriate. If done for 1.7.0, users'
installations will be doing an rpm-vercom of 1.610.0 against
1.7.0, which will obviously fail. If we do it by 1.7.0, then it'll
be 1.700.0 against 1.7.1, and I'm unsure of the result (though my
guess is 1.7.1 < 1.700.0, which would also fail). Answering this
question would clear the way to apply the patch I attached here
originally (cf. my last comment in r32364).
I played with rpm-vercomp for a while and confirmed that 1.7.1
would not be seen as newer than 1.700, as I expected; on the other
hand, the only way for users to selfupdate at present, other than
forcing, is for the new release to be called 1.700, as currently
planned, since 1.7 < 1.610 and 1.7.0 < 1.610. So as you can easily
see, all we would be doing is pushing the problem one-more-release
away by carrying on with floating point numbers until something
else is done.
So, if we want to solve the problem, if we consider it a problem
in the first place (do count me in with those who consider floating
point version numbers a little odd), I see no other solution but to
special-case the selfupdate proc that's soon to be released with
1.700:
Index: macports.tcl
===================================================================
--- macports.tcl (revision 43285)
+++ macports.tcl (working copy)
@@ -1876,6 +1876,10 @@
# get downloaded MacPorts version
gets $fd macports_version_new
close $fd
+ # Temporary and lame special-case to move away from floating
point version numbers:
+ if { $macports_version_new == "1.700" } {
+ set $macports_version_new "1.7.0"
+ }
# echo downloaded MacPorts version
ui_msg "Downloaded MacPorts base version $macports_version_new"
The selfupdate currently in users' hands would still do a simple
[rpm-vercomp 1.700 1.610] and would successfully proceed with the
upgrade. The special-cased selfupdate in 1.700 would then allow us
to release 1.7.1 or 1.8.0 and finally move away from floating point
version numbers by performing a manipulated [rpm-vercomp 1.7.0 1.7.1].
We could also, of course, choose to stick with floating point
version numbers forever more, but those being a tad odd is the
whole point of this thread ;-) Or we could also instruct users to
force...
Opinions? Regards,...
Definitely in favor of getting rid of the odd floating point version
numbers of MacPorts proper, especially since the version numbers of
all the software installed by MacPorts are assumed to be dotted
decimal numbers. (That of course needs to be fixed too, for the perl
ports and perhaps others that are released on a floating point
version numbering scheme [1].)
However, we have already cut 1.7.0-rc1 and it contains a year's worth
of great changes. I don't want to delay it any further, unless to fix
critical bugs, which this isn't. Let's put this in 1.8.0. There's no
reason we can't release 1.8.0 very soon after 1.7.0.
[1] http://trac.macports.org/ticket/11873
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
