Bug #4924


Todo #4224: PBIs are old skool. pkg-ng is the new shiny. We need to convert pfSense to use pkg-ng.

Package manager - the version comparison code not comparing versions properly

Added by Kill Bill over 8 years ago. Updated almost 8 years ago.

Package System
Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


Noted this with the recent packages cleanup spree... 10 > 9, the trailing 0 is not insignificant... :)

Actions #1

Updated by Phillip Davis over 8 years ago

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).

Actions #2

Updated by Phillip Davis over 8 years ago

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:
If that can be fixed first, then the version_compare functions in can also be used by the package version compare code.

Actions #3

Updated by Phillip Davis over 8 years ago

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 " pkg v.0.1.12" - changing this to " 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.

Actions #4

Updated by Kill Bill over 8 years ago

@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, or 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.

Actions #5

Updated by Kill Bill over 8 years ago

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...

Actions #6

Updated by Phillip Davis over 8 years ago

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.

Actions #7

Updated by Chris Buechler about 8 years ago

  • Status changed from New to Resolved
  • Target version set to 2.2.5

Pull request merged, thanks!

Actions #8

Updated by Chris Buechler about 8 years ago

  • Status changed from Resolved to Feedback

though that was on RELENG_2_2 only, was that fixed separately in master, or am I missing another pull request?

Actions #9

Updated by Phillip Davis about 8 years ago

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.

Actions #11

Updated by Chris Buechler about 8 years ago

  • Status changed from Feedback to Confirmed
  • Priority changed from Low to Normal
  • Target version changed from 2.2.5 to 2.3

Thanks Phil. This is good for 2.2.5.

For 2.3, since we're using pkg, that changes (as Renato mentioned on pull 1904). Moving target 2.3 to take care of updating for pkg.

Actions #12

Updated by Renato Botelho about 8 years ago

  • Assignee set to Renato Botelho
  • Parent task set to #4224
Actions #13

Updated by Renato Botelho about 8 years ago

  • Status changed from Confirmed to Feedback
  • % Done changed from 0 to 100
Actions #14

Updated by Chris Buechler almost 8 years ago

  • Status changed from Feedback to Resolved



Also available in: Atom PDF