On Dec 7, 2008, at 4:14 PM, Bryan Blackburn wrote:
So this will basically take care of #17420:
<http://trac.macports.org/ticket/17420>
In a way, yes: the logic to choose either the mp_version file or
macports_version is in the currently 1.610 released sources of
MacPorts, so if mp_version does not exist in the rsycn'd sources
(coming from svn), users' installations will still catch the freshly
downloaded macports_version file for the selfupdate run. So on that
aspect we're safe to delete mp_version.
However:
I did see some of the stuff you had done for moving to x.y.z fully,
but
wasn't aware of just how much was left to implement, hence the ticket.
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).
All this, of course, would be easily dealt with by instructing users
to force the selfupdate, but do we really want to consider that as a
alternative...?
Regards,...
-jmpp
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
