Ssu features are not updated on removal of the settings files

Bug Reports
,
#1

REPRODUCIBILITY (% or how often): 100%
BUILD ID = OS VERSION (Settings > About product): 4.1.0.24
HARDWARE (XA2, X10, X10 II, …): Xperia Tama; probably generic OS issue
UI LANGUAGE: -
REGRESSION: (compared to previous public release: Yes, No, ?): Don’t know

DESCRIPTION:

While adding ssu features (ini files under /usr/share/ssu/features.d/) adds new repositories as expected, removal of the files from there keeps repositories defined. This is due to the remaining definition in /var/cache/ssu.

STEPS TO REPRODUCE:

  1. add feature file under /usr/share/ssu/features.d/. For example, community-adaptation/adaptation-community-common.testing.ini at hybris-10 · sailfishos-sony-tama/community-adaptation · GitHub
  2. run ssu ur - repository will be listed when using ssu lr and used with zypper ref. So far, so good
  3. Remove the feature file
  4. Run ssu ur
  5. Repository is still listed with ssu lr and used with zypper ref

EXPECTED RESULT:

After removal and update of ssu, repository should not be used

ACTUAL RESULT:

Repository is still defined and used by package managers after removal.

ADDITIONAL INFORMATION:

To remove repository, we have to manually edit a file in /var/cache/ssu.

2 Likes
Announcing sailfishos:chum
[4.3.0.12] Issue with droidmedia
Community meeting on IRC 12th January 2023
#2

Another project which creates and removes repos removes the cache in %post of the spec droid-hal-configs/droid-configs.inc at master · mer-hybris/droid-hal-configs · GitHub

1 Like
#3

Used that fix - removal of cache for features and regeneration of it using ssu ur - and it worked well for chum repos.

Keeping it open as I believe it is still ssu bug.

#4

Added some rpm filetriggers to ssu to manage the cache a bit better: https://github.com/sailfishos/ssu/pull/3
Feature files should be packaged, and if one is removed during an uninstallation (e.g. feature-*) then the cache will be automatically reset. This change should make it into the upcoming 4.4.0 release.

#5

If I understand correctly this should now be fixed, so I’ve tagged it as such. @rinigus, am I understanding correctly?

#6

Haven’t tested it on device, so take it accordingly. Looking at PR, I don’t see how changes in SPEC would fix it. Although there is some magic call %transfiletriggerin - no idea what it does.