Dear list, Yesterday, port -v outdated informed me that there was a "new" version of MPlayer available: Mplayer 1.0rc1_4 > 1.0rc1_try3 ! Yes, _4 is the one I had, _try3, the new one. try3 is a strange name for a revision, but it is the official branding, so... As try3 corrects a security bug, I upgraded* and have now installed it: The following ports are currently installed: MPlayer @1.0rc1_4+binary_codecs+caca+darwin_8+darwin_powerpc+freetype+macosx+x11+xvid MPlayer @1.0rc1_try3+binary_codecs+caca+darwin_8+darwin_powerpc+macosx+osd+x11+xvid (active) But port outdated has a really strange output: The following installed ports are outdated: MPlayer 1.0rc1_ < 1.0rc1_try3 There is definitely something strange here. Emmanuel 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.
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 to: 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
Citando Boey Maun Suang :
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
to:
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 ).
Yes, I use -v when I do port outdated (this way I can check if some updates to portfiles have been committed, and also remind me to put a ticket if I have not yet). However I did not "force" upgrade but installed manually as the variants have changed (+freetype and +fontconfig have disappeared in favor of +osd).
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).
Ticket on trac: http://trac.macports.org/projects/macports/ticket/12204 I don't know which milestone I should have put (Needs developper review, MP1.4 or MP1.5) so I put none.
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!
It is almost resolved: http://trac.macports.org/projects/macports/ticket/12196 . It is more or less my bad for not deinstalling lzo after installing lzo2. Emmanuel
On Jun 29, 2007, at 8:17 AM, Emmanuel Hainry wrote:
Citando Boey Maun Suang :
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
to:
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 ).
my bad here... I was trying to do the minimal amount of hacking to deal with MPlayer's stupid non-versions. My testing didn't turn up any cases where revision was expected to be numerical, and 't' is > '4' so it did correctly detect as being newer.
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!
It is almost resolved: http://trac.macports.org/projects/macports/ticket/12196 . It is more or less my bad for not deinstalling lzo after installing lzo2.
Not really your fault, I had the -I ordering wrong. But since almost nothing needs lzo1 most people should uninstall it once they upgrade. Could someone apply the change in that ticket and commit? Thanks, Eric
On 30 Jun, 2007, at 12:26, Eric Cronin wrote:
On Jun 29, 2007, at 8:17 AM, Emmanuel Hainry wrote: Not really your fault, I had the -I ordering wrong. But since almost nothing needs lzo1 most people should uninstall it once they upgrade. Could someone apply the change in that ticket and commit?
I've done so. Chris
participants (4)
-
Boey Maun Suang
-
Chris Pickel
-
Emmanuel Hainry
-
Eric Cronin