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
Noted this with the recent packages cleanup spree... 10 > 9, the trailing 0 is not insignificant... :)
- Use complete name for get_pkg_info() filter parameter
- Remove unnecessary calls to verify_all_package_servers and
- Remove unused and commented out tabs
- Use new pkg_version_compare() to compare package version, it
- Remove already disabled 'Reinstall GUI'
- Fix Info button
#2 Updated by Phillip Davis almost 4 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 pfsense-utils.inc can also be used by the package version compare code.
#3 Updated by Phillip Davis almost 4 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 "22.214.171.124_2 pkg v.0.1.12" - changing this to "126.96.36.199_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.
#4 Updated by Kill Bill almost 4 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 188.8.131.52_2, or 184.108.40.206-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.
#5 Updated by Kill Bill almost 4 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...
#6 Updated by Phillip Davis almost 4 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.
#9 Updated by Phillip Davis over 3 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.
#11 Updated by Chris Buechler over 3 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.