Active version of p5-xml-parser is not 2.400.0_1 but 2.40_1+universal

[ryandesign (Ryan Carsten Schmidt)]

I was holding off on syncing for awhile, while the perl5 explosion settled down, but I appear not to have waited long enough:

$ sudo port -u upgrade libqalculate openbrowser libgpod
--->  Computing dependencies for p5.12-xml-parser
--->  Fetching archive for p5.12-xml-parser
--->  Attempting to fetch p5.12-xml-parser-2.400.0_2.darwin_10.x86_64.tbz2 from http://packages.macports.org/p5.12-xml-parser
--->  Fetching p5.12-xml-parser
--->  Verifying checksum(s) for p5.12-xml-parser
--->  Extracting p5.12-xml-parser
--->  Configuring p5.12-xml-parser
--->  Building p5.12-xml-parser
--->  Staging p5.12-xml-parser into destroot
--->  Installing p5.12-xml-parser @2.400.0_2
--->  Activating p5.12-xml-parser @2.400.0_2
Error: Target org.macports.deactivate returned: Active version of p5-xml-parser is not 2.400.0_1 but 2.40_1+universal.
Log for p5-xml-parser is at: /opt/local/var/macports/logs/_opt_local_var_macports_registry_portfiles_p5-xml-parser_2.40_1+universal/p5-xml-parser/main.log
Warning: Failed to execute portfile from registry for p5-xml-parser @2.40_1+universal
--->  Deactivating p5-xml-parser @2.40_1+universal
--->  Cleaning p5.12-xml-parser
--->  Computing dependencies for libqalculate
--->  Fetching archive for libqalculate
--->  Attempting to fetch libqalculate-0.9.7_1.darwin_10.x86_64.tbz2 from http://packages.macports.org/libqalculate
--->  Fetching libqalculate
--->  Verifying checksum(s) for libqalculate
--->  Extracting libqalculate
^C

I assume this is a general perl5 portgroup problem and is not specific to the p5-xml-parser port(s).

[ryandesign (Ryan Carsten Schmidt)]

This was also ​reported on the macports-users list against p5-locale-gettext.

[fracai]

This affects several portfiles. Without taking an extensive look, it seems that anything with a '0' causes a problem. '1.09' will be turned into '1.90' for example. I imagine this is going to cause all sorts of problems when new versions are submitted.

[fracai]

Cc Me!

[fracai]

I've looked into this further and it's not an issue with '0's, but with how the version string is being manipulated.

As near as I can tell, the code is meant to split a version string into groups of 3 digits. 1.123456 would turn into 1.123.456. Unfortunately it's turning 1.1234 into 1.123.400 instead of 1.123.004. At least, I assume that 1.123.004 is the intended value. I'm not really sure why this version manipulation is required. Hopefully JMR can comment there.

The relevant code is the 'perl5_convert_version' method of trunk/dports/_resources/port1.0/group/perl5-1.0.tcl​.

I started modifying this to prepend '0's instead of appending them, but the return uses 'scan' which strips out the leading '0's anyway. Again, it'll be up to JMR to decide whether the scan should be dropped or if the version alteration is needed at all.

[fracai]

Modification to 'perl5_convert_version'.

[fracai]

For what it's worth, attached is a diff that produces the '1.123.004' behavior.

[trog24 (Frank J. R. Hanstick)]

Cc Me!

[drkp (Dan Ports)]

What's going on here is that the way the perl portgroup generates version numbers changed. (My understanding is that perl version numbers are floating point, i.e. 1.123.4 is supposed to be greater than 1.123.399, and our normal version comparison does not see it that way. See #11873 for more info.)

But how or why the version numbers changed isn't actually relevant to this bug. The problem is that when it comes time to deactivate or uninstall the old version, MacPorts finds and runs the copy of the old version's portfile that's saved in the registry, to check for post-uninstall/post-deactivate hooks. The version number of that portfile ought to match the installed port --- and usually it does --- but here it doesn't, because it's using the old portfile but the latest version of the *portgroup*, and that's where the version conversion happens.

As far as I'm aware, this doesn't actually cause any problems other than the ominous-looking error message. But it's sufficiently alarming that I'd like to do something about it... but what?

One option would be to have base save in the registry the corresponding version of the portgroups used for the portfile. Another would be to use a different version number for the perl5 portgroup, i.e. perl5-1.0 and perl5-2.0. Either way, it isn't really clear what to do now, after the fact.

[fracai]

Gotcha.

For me at least, the reason that I thought a problem was being caused is that the actual Portfiles don't state that they've been replaced by the major perl version (p5-xml-parser is replaced by p5.12-xml-parser). You need to run a port command to see that. So I was thinking that some ports might end up left referencing the old, non-unified port.

It sounds like all that's needed is a better warning. Or at least a message to the users list for others who haven't checked this ticket.

[skymoo (Adam Mercer)]

Cc Me!

[ghosthound]

Cc Me!

[blair (Blair Zajac)]

Cc Me!

[jjstickel@…]

Cc Me!

[sewebster@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #31176.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #31281.

[ryandesign (Ryan Carsten Schmidt)]

What we should have done is left the perl5 1.0 portgroup alone, and copied it to create a new perl5 1.1 portgroup, and updated the ports to use that. But it's too late now; everyone's already upgraded past this situation now. I think we can close this as "wontfix".

[jmroot (Joshua Root)]

Shouldn't be an issue any more with portgroups kept in the registry.