mplayer revision try3

Boey Maun Suang boeyms at
Fri Jun 29 01:52:58 PDT 2007

Hi Emmanuel,

> 	Yesterday, port -v outdated informed me that there was a "new"
> version of MPlayer available:
> Mplayer	1.0rc1_4 > 1.0rc1_try3 !

The revision field in Portfiles is only supposed to be used for  
updates or fixes to the Portfile that don't involve upstream changes,  
and furthermore is only intended to contain positive integer values.   
In this case, the Portfile should have been altered from:

version		1.0rc1
revision	4


version		1.0rc1try3

(i.e. the revision number should have been removed; it should default  
to 0).

Eric, would you be able to make this change?  I don't think that it  
will muck up the revisioning, since the version comparison algorithm  
used in MacPorts will report 1.0rc1 < 1.0rc1try3.  I suspect that  
Emmanuel had to force MacPorts to upgrade Mplayer in the first  
instance, as his output indicates that MacPorts thought on the basis  
of the strings that the installed version is newer than the "updated"  
version, so not many users will have installed the current version in  
the tree (including myself :P ).

> But port outdated has a really strange output:
> The following installed ports are outdated:
> MPlayer                        1.0rc1_ < 1.0rc1_try3

Though I haven't checked the code, I suspect that problem is that the  
code that records values into the registry borked when told to store  
a non-numerical value into the revision field, and stored a null  
value instead; "port outdated" then checks the epoch (equal, both 0),  
version (equal, both 1.0rc1), and then revision (installed NULL <  
newest "try3", as NULL will evaluate to less that the character  
"t").  If you could create another ticket describing this and  
suggesting that the code check for the values being set in revision  
(in portindex.tcl and/or in the registry code), that would be great  
(I'm having trouble logging into Trac at present).

> PS: * the upgrade did not go perfectly, I had to change the  
> Portfile to
> revert the dependency on lzo instead of lzo2. I will put a ticket on
> track.

Not sure about this one.  Eric, I suppose it's over to you!

Kind regards,

Maun Suang

Boey Maun Suang (Boey is my surname)
Email: boeyms at macports dot org

More information about the macports-users mailing list