Software depends on Qt patch version?

[iago-lito]

My GUI stopped working today, with the following error :(

$ SLiMgui
Run-time Qt version 5.15.13 does not match compile-time Qt version 5.15.12

(installed from the AUR)

Patch-upgrades of Qt should maybe not be blocking, as they are supposed to be non-breaking?

Note that the problem was easily fixed by re-building SLiM: the question is whether checking minor and patch version numbers is necessary. If so, then it is not a bug in SLiM, but in this distributed package.

[bhaller]

It is probably excessively conservative, yes; according to the Qt folks, there shouldn't be a problem. But if there were a problem, it could result in hard-to-diagnose bugs, and possible incorrect simulation results. Given that recompiling is trivial, I am inclined to require the version numbers to match exactly, unless some strong reason not to do so arises.

You say:

If so, then it is not a bug in SLiM, but in this distributed package.

In what way? What does the package have to do with it?

[iago-lito]

Agreed. Better be conservative here than having users get ugly bugs to investigate. I'll close this then, because strict version checking is not actually an issue under this perspective :)

What does the package have to do with it?

I am not 100% sure how AUR packages work, but I would have expected the install script, considering that my Qt library had been bumped, to figure on its own that it needed recompilation during my last system upgrade. Not an issue for SLiM though. Maybe the fix is to tweak something inside that install script, but I am unfamiliar with PKGBUILD files yet.

[bhaller]

@grahamgower Possibly something for you to contemplate here, particularly if the standard Qt version has moved to 5.15.13. Note that I intend to release SLiM 4.2 within the next couple of days, so there is no need for you to do anything for the current package. :-> Thanks!

[grahamgower]

SLiM's behaviour of comparing the (minor) version of a dynamically linked library against the version of the headers that were used at compile time is fairly atypical. I don't think there's anything the Arch package script should be doing to also detect this situation. What do the various other packaging systems do? I assume they also require some kind of forced rebuild after the user has updated the Qt libs? Does SLiM's cmake build scripts even detect this?

Edit: if SLiM really doesn't trust the binary compatibility guarantee provided by Qt, then this would be an argument in favour of static linking instead.

[bhaller]

IIRC, static linking against Qt proved to be quite complex. Qt is a complex beast. I'm happy with the current state of affairs if the rest of you are. :-> And no, SLiM's cmake doesn't think about this; this condition is detected only at runtime. It really doesn't arise often, since people don't update Qt out from under SLiM often. I just thought you might want to know about it, @grahamgower. :-> If folks feel strongly that I ought to relax the test, I could; but it makes me nervous. Why rely on a compatibility guarantee if you don't have to? Why not just rebuild?

[iago-lito]

I am very okay with rebuilding when needed, and closing this as "not important enough regarding the burden of fixing". SLiM is a niche software which I think only few people use compared to Qt or pacman, and I guess very few other programs actually depend on it. As a consequence, the pressure on making its packaging/distribution super-perfect is very low.

This being said, I have been delighted to learn that there was a package for SLiM on the AUR. Installing SLiM on my machine and keeping it up-to-date has been a breeze so far :) Thank you a lot for this @grahamgower <3

[bhaller]

OK, let's leave this closed then, and not worry about it unless/until it manifests in some more problematic way.