https://bugzilla.suse.com/show_bug.cgi?id=1226517 Bug ID: 1226517 Summary: After snapper rollback/restore marks packages as explicitly installed which were autoinstalled previously Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs@suse.de Reporter: ors0092@gmail.com QA Contact: qa-bugs@suse.de Target Milestone: --- Found By: --- Blocker: --- Yesterday, I filed a bug report directly on Snapper's upstream GitHub, as I was advised to do so on the Matrix support chat (https://github.com/openSUSE/snapper/issues/916). However, the issue was closed and I was redirected here. Two days ago, I accidentally noticed something strange. I don't know if this is how Snapper is supposed to work, but here are my observations and steps to reproduce: 1. I installed `firewall-applet` manually, and zypper marked it with `i+` as explicitly installed. It also pulled `firewall-config` automatically as a dependency (marking it with `i` as auto-installed status) - so far, so good. 2. Then, I did a `sudo zypper rm --clean-deps firewall-applet`, and it perfectly caught `firewall-config` too, as it was installed automatically as a dependency. 3. Next, I did a reboot and told Snapper to use the `post` snapshot from the time when `firewall-applet` was installed. This reverted the removal process to the point where `firewall-applet` was installed instead, so chronologically we are at step 1. 4. In the read-only mode, I did a `zypper se -i firewall-`, and to my surprise, `firewall-config` was also marked with `i+`. 5. I made the `sudo snapper rollback` to see the changes live, and yes, `firewall-config` was still marked with `i+`. 6. When I did `sudo zypper rm --clean-deps firewall-applet`, it no longer recognized `firewall-config` to be auto-removed since it was marked as explicitly installed. 7. This can be also reproduced without rebooting when steps are done from the GUI YaST2 snapshot tool. 8. Since it was late yesterday, I thought I was too tired and maybe misunderstood something. So, I double-checked myself and simulated the steps I made yesterday, just to confirm my theory, and yepp - same results. No idea why, but snapper removes any affected packages during a snapper procedure within `/var/lib/zypp/AutoInstalled` but this step is nowhere logged. Also an additional question for us affected users: how do we trace back which packages were marked by these rollbacks? As you might guess, there could be plenty of unnecessary packages using extra drive space, now that are explicitly marked and thus never get removed via `sudo zypper dup --remove-orphaned` nor gets listed by `zypper pa --orphaned` or `zypper pa --unneeded` sadly. 4years ago it seems it got already uncovered under boo 1175304, but is also reported under Leap, this ticket is all about Tumbleweed experiences. Operating System: openSUSE Tumbleweed 20240617 KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 Kernel Version: 6.9.4-1-default (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-6500 CPU @ 3.20GHz Memory: 15.6 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1050 Ti/PCIe/SSE2 Manufacturer: MSI Product Name: MS-7972 System Version: 2.0 -- You are receiving this mail because: You are on the CC list for the bug.