pfSense

I am looking at that. Yes, it needs smarter comparison and might be able to reuse code that does similar stuff for comparing pfSense version upgrades (e.g. pfSense 2.2.9->2.2.10 might suffer a similar fate - I will double check).

Note that this is also a problem for a pfSense version upgrade from 2.2.9 to 2.2.10 and the like, due to a bug in the version check in a different place to this one. See:
https://redmine.pfsense.org/issues/4925
https://github.com/pfsense/pfsense/pull/1810
If that can be fixed first, then the version_compare functions in pfsense-utils.inc can also be used by the package version compare code.

The current packages has quite a few "non-standards" for writing the package version:
1) "n.n" or "n.n.n" - like pfSense

2) "n.n.n_n" - some binaries have things like ntop does "5.0.1_4" - these will have the problem going from "5.0.9_2" to 5.0.10_1" for example. Easy enough to cope with this format also.

3) starting string (1) or (2) indicating the binary version followed by something to indicate the pfSense "PHP" package version:
a) "n.n.n_n vn.n" (using "v" or "V")

b) DansGuardian has "2.12.0.3_2 pkg v.0.1.12" - changing this to "2.12.0.3_2 v0.1.12" would help!
Similar is done for Squid

c) arpwatch "2.1.a15_8 pkg v1.1.2" - The initial "n.n.n"-style stuff can have alphas in it. SquidGuard-devel "1.5_1beta pkg v.1.5.6"

d) Havp Antivirus "0.91_3 pkg v1.05_1" - the "PHP" package version can have the "n.n_n" style also. And numbers can have leading zeroes - I guess "1.05" to "1.5" should be an upgrade? "1.09" to "1.10" is an upgrade? "1.09" to "1.1" is an upgrade?

e) urlsnarf "2.4b1" is another thing done after the first "n.n"

f) Zabbix is like "zabbix24-agent-2.4.3 pkg v0.8.3" - various words and dashes in the start of the string. "apcupsd-3.14.12_1 pkg v0.3.6" is in a similar style.

We can make a generic comparison function that splits the full package string into components that look like "genuine integers" and "other chunks". Then it can compare each chunk - compare the "string-looking" chunks with strcmp() and when both are "genuine integers" then compare with ordinary > and <. That way a 9 and 10 in the same chunk will compare with 10 being greater. But "05" and 1 will be compared using strcmp() and 1 comes out later - that will handle projects that put out version numbers like 6.01 6.02 6.03... and then release 6.1 - in that case their "numbering" is really string-oriented.

@Phil: IMO, those completely whacky package versions should not be a concern here. I'm replacing them as I clean something up. And pfS guys have been doing the same before to de-couple the upstream code version from the internal XML package version. (The downside ATM is that there no XML foo to display the upstream version in the GUI. Will probably change when you can use the FreeBSD `pkg` to get and display the upstream version.)

IMO, some valid versioning schem needs to be followed, not random crap like zabbix24-agent-2.4.3 pkg v0.8.3 Things like 2.12.0.3_2, or 2.12.0.3-2 should remain "valid" and considered for comparisons, though, the stripped trailing .0 is bad as well. There are are some widely accepted conventions elsewhere in package managers, like foo-1.0_p? > foo-1.0 > foo-1.0_rc? > foo-1.0_beta? > foo-1.0_alpha? but not really sure whether it's worth the hassle here.

Another note on the above... It's really pfS that sets up the rules what's considered valid here -- and this stuff could (heck, probably even should ) be validated and enforced. Now you generally have no need to deal with the various upstream versioning scheme oddities. The above was just some exaple, others cases are, e.g.; 1.0.1c > 1.0.1b > 1.0.1a > 1.0.1, or using decimal versions after the separators, like 2.3_beta1.5...

I made a generic version comparison function. That should handle all the rubbish that is there now, and also continue to work just as well if someone cleans up the "version description standard" to be used for packages.
https://github.com/pfsense/pfsense/pull/1811

Yes, that was RELENG_2_2 only. At the time the package system code was actively being worked on by Renato in master, for getting rid of PBI. So there was no point trying to make a version for master.

Is the package code in master now the (reasonably barring bugs) stable version going forward?

If so, then I will look at it and make a pull request for the similar relevant changes to master.

Pull request for master:
https://github.com/pfsense/pfsense/pull/1904