Discrepancy in upgradeable package results between MXPI_EnabledRepos and MX Updater [Solved]

[dolphin_oracle]

its possible the heurstic for version comparison has a flaw.

Code: Select all

(25.08.06) over (25.8) 

I think .08 is coming up as not an upgrade over .8

because the same problem does not occur betwen 25.08.04 and 25.08.06. @fehlix using the August snapshot was key, because the problem wasn't showing up on my update-to-date system, nor on the 23.6 official release.

[fehlix]

its possible the heurstic for version comparison has a flaw.

Code: Select all

(25.08.06) over (25.8) 

I think .08 is coming up as not an upgrade over .8

because the same problem does not occur betwen 25.08.04 and 25.08.06. @fehlix using the August snapshot was key, because the problem wasn't showing up on my update-to-date system, nor on the 23.6 official release.

Probaly, b/c trying to re-invent in c++ what dpkg with "--compare-versions" offers, may look simple but can lead to wrong results,
if you want handle all potential cases debian package version number can be.
E.g this looks simple, a full re-implemtation for package version comparision is far from simple:

Code: Select all

dpkg --compare-versions  "25.08.06" "gt" "25.8" && echo YES
YES

or this

Code: Select all

dpkg --compare-versions  "25.08.06" "gt" "25.08" && echo YES

But not sure that's this is actually the issue, maybe it is. Or something else, b/c if I remember I have seen this occasionally but ignored,
similar to the OP.

[Adrian]

I think I fixed it, the issue was that our VersionNumber was considering 25.8 different than 25.08 while dpkg treats them as the same version.

I have to "reinvent the wheel" and use C++ for a good reason: it's very expensive to call an external tool every time I have to compare two versions.

[fehlix]

I think I fixed it, the issue was that our VersionNumber was considering 25.8 different than 25.08 while dpkg treats them as the same version.

I have to "reinvent the wheel" and use C++ for a good reason: it's very expensive to call an external tool every time I have to compare two versions.

yes, but it is not simple as it looks like.

[Adrian]

I think I fixed it, the issue was that our VersionNumber was considering 25.8 different than 25.08 while dpkg treats them as the same version.

I have to "reinvent the wheel" and use C++ for a good reason: it's very expensive to call an external tool every time I have to compare two versions.

yes, but it is not simple as it looks like.

It never is...

[retroD0d0]

Wow Team MX, already fixed with the latest MXPI update! Your efficiency impresses! MXPI and MX Updater now in agreement. My thanks to the devs for cracking heads together and finding the solution and also to everyone who took the time to reply.

I prefer to use Enabled Repos over MX Updater since it gives granular control over which updates to do immediately and which to delay. Over time, you learn that, with certain packages/maintainers, it is better to let the dust settle on an update, rather rushing to install a bad update and then having to do a re-update just to fix it. To my mind, critical security updates notwithstanding, package updates are not a race.

Have a great day/night everyone.

[retroD0d0]

I might have jumped the Gun a little, seems like there is another fail condition for the version-check in the funky naming scheme used in the libxslt package(see pic). We're getting nearer at least!

edit: My bad, I didn't uncheck the 'hide library packages' and do another immediate refresh. It's picking up libxslt now. All fine, nothing to see.