Local versions of many packages are newer than those in the AUR

I think you will find that there is no single reason for this. Each case has to be investigated individually.

If you mean the -git thing, that shouldn’t be common. The installed version of -git package shouldn’t be newer than what is referenced in AUR. The opposite is common where it is older. If a *-git package has that warning, the maintainer should really fix it.

1 Like

Well, good luck then. You clearly don’t need help.

Unfortunately, I think more and more that this is likely.

But the explanation seemed quite convincing. So if there is a non-downgraded or outdated package in the AUR, it is not possible to know why the local version is newer than the one in the AUR.

The explanation is convincing because it is a real thing but it actually works in the opposite direction. In other words, it causes the versions to appear older as opposed to newer. That is because the version in AUR doesn’t change while the version on your system does. For that to cause a situation where the package on your system is newer would be very odd. It is theoretically possible, but it would probably indicate a mistake on the part of the AUR maintainer or something exceptionally strange happening to the code base. Like someone force pushed an older version. None of that should be common.

It is possible. It just requires individual investigation and research.

I’ve got to disagree on this one. I think the only reason that it’s not more common is that 1) Most git repos aren’t that volatile, and 2) Yay (don’t know about paru, etc.) won’t rebuild a “-git” package unless the maintainer updates it or you specify the “–devel” flag.

It all comes down to repo volatility and package maintainer’s tenacity.

That said, as you pointed out, there is no one single reason for the message.

No matter how much the git repo changes, what would be the scenario where the version on the system would be newer?

Like I said, most “-git” packages generate a version number based on the tags in the repo. That’s why you’ll see a version number like “1.0+r69_abcdefabcdef”. If there have been any commits since the package maintainer’s last update, the version number will be different and higher.

Example: try installing “vlang-git” and then update it a few hours later. (Vlang seems to get lots of updates.)

Agree. If a freshly compiled AUR package has a lower version than the installed one, something is wrong with the pkgver() function. It should never result in a version that is older when commits are added.

Right. So we’re all on the same page I guess ?!?

1 Like

Yes, exactly.

However, that creates a situation where the installed version is older, not one where the installed version is newer.

No, because makepkg updates the version field of the PKGBUILD file as a result of the pkgver() function.

Yes. Yes, we are.

Can provide a real example of which a major AUR helper calculates that message that way? If it worked the way you are describing, every AUR helper would be warning about newer packages on every devel update.

It’s literally a function in the PKGBUILD file.

I understand how it works but it doesn’t make the installed version newer. The AUR helpers like yay/paru either exclude functions with a pkgver function or calculate the new version before giving that warning so that scenario shouldn’t trigger that warning.

1 Like

I just ran a test with yay and stand somewhat corrected.

Apparently yay is aware that the build updated the package version and suppresses the “newer version” message. The package has the updated version, so pkgver() is not being excluded.

The resulting (built) package will have the version that is computed with pkgver() of course

Talking about yay: For the version comparison of a -git package, it stores the commit hash in the source repo locally (.cache/yay/vcs.json) when the pkg is built. When looking for updates it’ll compare that vs. whats currently HEAD in the source repo…