Unsatisfiable dependencies in a previous COPR build/release

I maintain a Copr repository for an upstream project. During the latest upstream release, my first two builds were successful, but because I was not aware that an update to Qt5 was pushed on Fedora Updates my package was built against a different release of Qt5 than what the Requires: specified.

I realized this upon testing an upgrade from the repository on my machine and addressed it with a new build from an updated spec file.

This can cause dependency issues if a user is installing software that requires the previous point release of Qt5. DNF will downgrade the package I maintain and this breaks the run-time Qt5 dependency, because it was built against a newer version but the package spec indicates an older version for that build of the rpm.

Am I able to disallow distribution of the earlier releases of the package from the Copr repository, so that users do not find themselves with a broken version of the package?

Normally, you don’t need to specify a requires if you already have a build dependency, rpm will automatically take care of runtime for you. At least I haven’t had any issues in that regard. Regarding dependencies, if an install/upgrade will break an existing installed package, it should fail. Likewise, DNF will always try to install the latest package available, unless a specific version is specified - but if that specific version would doesn’t have the correct dependencies available, it should fail. Also, I believe the owner can delete builds on copr if they wish.

I didn’t know that RPM would automatically determine runtime requirements from BuildRequires. I’ll see if that works for this project.

The install doesn’t fail because DNF is led to believe that everything is satisfiable because of the mistake in the program.rpm itself. If DNF thinks that a downgrade of the package will allow it to run against a version of Qt5 common to other system or user packages, then it will propose that downgrade. The issue is that the actual binary is compiled against a different version of Qt5, and the program will not work; DNF is not aware of this, however.

I did delete earlier builds of the program on my Copr repository. Attempting a downgrade of the package now indicates that only the corrected release of the package is available, now that the DNF metadata on my system has expired and the rebuilt metadata of the Copr repository has been synced.

Here is something that might help: https://linux.m2osw.com/find-qt-version-command-line-compile-time-run-time

Personally, I’ve never encountered the issue you are describing, maybe I’ve just been lucky. Typically, as the above link states, qt libraries are backward compatible - maybe your particular application is the exception to the rule.

Yes, the application I package has that issue. If the gui is launched from the command-line it reports that the compile-time and run-time versions of Qt5 are different and the program fails to launch. Qt is an interesting framework, but I’m not a developer and I really couldn’t look into the issue: the developer of the program has looked into it without success.

Deleting the improper builds from the Copr repository solves the issue for any users of the application, however. I have instructions for users if they find themselves in the unfortunate situation of having outdated repository metadata and a broken package.