search

sailfishos-chum / main

Documentation and issue tracker for the SailfishOS:Chum community repository
https://build.merproject.org/project/show/sailfishos:chum
MIT License
26 stars 4 forks source link

[rpm] Added repositories become outdated after a SFOS upgrade? #64

Closed Olf0 closed 2 years ago

Olf0 commented 2 years ago

Issue description

The repositories added by the spec file point to the wrong SailfishOS release version after a subsequent SailfishOS upgrade, because AFAICS there is no mechanism which updates them.

Possible resolution

Hence a mechanism is needed, which either is triggered by a SFOS upgrade or detects that these repo entries have become stale soon after a SFOS upgrade (i.e., do not match the installed SFOS release any more, as retrieved per grep -F VERSION_ID /etc/os-release | cut -d '=' -f 2), and updates these repository entries accordingly.

Workaround

As an awkward workaround until a proper resolution is available, users can remove ("uninstall") and re-install the SailfishOS:Chum RPM after a SailfishOS upgrade.

References

Line 41 and line 46 of the spec file

rinigus commented 2 years ago

Are you sure it becomes outdated? As it expected to go as a macro into corresponding files "%(release)_%(arch)"

Olf0 commented 2 years ago

Are you sure it becomes outdated?

No, I have not tested an SFOS upgrade with these entries present.

As it expected to go as a macro into corresponding files "%(release)_%(arch)"

Oh, I see what the intention is. It is only the ssu lr does not show the real content, but with "%(release)_%(arch)" replaced by the current values. Sorry, I assumed the macros to be expanded by the rpm utility, not by ssu. But for rpm they would have to be "%{release}_%{arch}". Edit: After having researched the "corresponding file", which is /etc/ssu/ssu.ini: Yes, indeed grep -F sailfishos-chum /etc/ssu/ssu.ini shows the entry as "%(release)_%(arch)".

Thus closing.