I host a repo for a project of mine called SecondFaqtor, which uses Gambas3 and generally doesn’t need anything fancy like the OS version or the architecture. For most distros, the one-size-fits-all noarch, no releasever, barebones rpm-md system works fine. However, for Fedora Workstation and openSUSE, this system does not quite work as expected.
In Fedora’s case, I had to make a unique fc## build for each supported Fedora version and include $releasever in the baseurl to fix dist-upgrades. Otherwise, every OS bump resulted in a “package.2.5.5-1.fdr.noarch already installed” showstopper.
However, in SUSE, the problem is a little less problematic, and a little harder to resolve. “zypper up” is entirely unaffected, but every time I run “zypper dup”, my package gets reinstalled. Every single run yields the same result:
The following package is going to be reinstalled:
secondfaqtor
1 package to reinstall.
Overall download size: 95.5 KiB. Already cached: 0 B. No additional space will be used or freed after the operation.
I tried adding a $releasever to the baseurl, with separate builds using both the older lp154 and newer 150400 numbering schemes, but the reinstall prompt persists.
Exactly which elements and properties contribute to a package being marked for reinstall during a dist-upgrade?
Even if you let it reinstall and then immediately do zypper dup again?
Precisely. It’s a very odd behavior.
Well, you could at least provide the link to your project so that someone may try to reproduce it.
Sorry, always reticent to post URLs with new accounts. The REPOfile is available at https://repo.realityripple.com/suse.repo
An lp154-style multi-version test for 15.3, 15.4, and 15.5 is available by changing the baseurl to https://repo.realityripple.com/.suse/$releasever/. Or a single 150000-style entry using https://repo.realityripple.com/.suse/.
And installation instructions for the only package currently available on the repo is available at https://repo.realityripple.com/suse/#secondfaqtor.
The repository metadata does not match package information.
Repository metadata:
solvable:buildtime: 1680994879
package metadata (from installed on the system)
solvable:buildtime: 1681020079
That is exactly 7 hours difference.
P.S. how this question is related to Open Build Service? It is more in place on Applications or Installation.
1 Like
If it’s exactly 7 hours off, it must be a timezone thing… And, I think I narrowed it down. A Date() constructor function that I expected to be in universal time that’s instead localized. Thanks for finding that! Hopefully that’s the culprit!
And I put it in this category because I wasn’t sure where the actual issue is; whether it was something the build service does that I was missing, whether it was some filesystem structure thing on the repo, or whatever else. Hopefully it is just that timezone-offset metadata value, though!
Yep, that Date() function was the culprit, and the correct timestamp has resolved the issue! Thanks for your help narrowing that down!