Moving MacPorts to the x.y.z version format internally for 1.7.1/1.8.0

[Juan Manuel Palacios]

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