[Amadeus-22]

"Ignore the current update for this package" adds the package to the blacklist, but after a refresh the update can still be listed. Automatic upgrades can also install it even when the blacklist was exported to /etc/mintupdate.blacklist. This happens when a binary's version is different from its source package's version. That covers epochs (bsdutils 1:2.39.3-9ubuntu6.6 from util-linux 2.39.3-9ubuntu6.6), -signed packages (grub-efi-amd64-signed 1.202.5+2.12-1ubuntu7.3 from grub2-signed 1.202.5) and binNMUs. When only some of the binaries differ, part of the update stays: for util-linux, bsdutils alone remains in the list.

This looks like the cause of #682 (grub2-signed), #891 and #750. All three were closed by the stale bot without a fix.

Root cause: since 7a79b61 ("Blacklist: Allow right-click blacklisting of multiple source packages grouped as a single update"), the menu entry stores source=source_version (Update.source_packages, usr/lib/linuxmint/mintUpdate/Classes.py:68 and :125). Both checks still compare the entry with a binary version:

• AptUpdater.is_blacklisted() is called with package.candidate.version (usr/lib/linuxmint/mintUpdate/aptUpdater.py:303 on master).
• mintupdate-cli has its own copy of the function and compares the entry with update.new_version (usr/lib/linuxmint/mintUpdate/mintupdate-cli.py:68). That value is the binary version of the last package added to the update.

The change moves the rule into a single is_blacklisted(blacklist, candidate) function in aptUpdater.py, and the update list and mintupdate-cli now both call it. A versioned entry matches when its version equals either the candidate's source version or its binary version. Entries typed in Preferences with the version shown in the update list keep working, and fnmatch patterns on the name work as before. mintupdate-cli now checks every package of an update and skips the whole update if any package matches, so the result no longer depends on which package happens to be first or last in the update.

Automatic upgrades run mintupdate-cli as root and only read /etc/mintupdate.blacklist. They see a "current update" entry only if the user exported the blacklist from Preferences after adding it. This PR does not change that.

Tests: there is no test suite on master (tests/ was removed with the kernel window), so I added tests/test_blacklist.py. It uses the standard library's unittest and stub packages, and forces the memory GSettings backend, so it reads nothing from APT or dconf. It still needs the com.linuxmint.updates schema to be installed, as on any Mint system. It runs the real AptUpdater.add_update() and runs mintupdate-cli.py as a script through runpy, with a stubbed cache and no /etc/mintupdate.blacklist.

$ /usr/bin/python3 -m unittest discover -s tests
Before (origin/master, 19bca4c0):
FAIL: test_ignore_current_update_epoch (test_blacklist.TestCli...)
AssertionError: Lists differ: ['grub2-signed', 'util-linux'] != ['grub2-signed']
FAIL: test_ignore_current_update_signed (test_blacklist.TestCli...)
AssertionError: Lists differ: ['grub2-signed', 'util-linux'] != ['util-linux']
FAIL: test_ignore_current_update_epoch (test_blacklist.TestUpdateList...)
AssertionError: 'util-linux' unexpectedly found in {'util-linux': ['bsdutils'], ...}
FAIL: test_ignore_current_update_signed (test_blacklist.TestUpdateList...)
AssertionError: 'grub2-signed' unexpectedly found in {..., 'grub2-signed': ['grub-efi-amd64-signed']}
Ran 12 tests, FAILED (failures=4)

After:
Ran 12 tests in 0.005s
OK

The other 8 tests pass both before and after. They cover binary-version entries, name patterns, entries for another version, and the case with nothing ignored.

I also reproduced it end to end on Mint 22 (noble), using a copy of the dpkg status file with grub-efi-amd64-signed set back to 1.202+2.12-1ubuntu7 and passed through APT_CONFIG. Nothing was installed and nothing ran as root:

$ APT_CONFIG=fake.conf /usr/bin/python3 mintupdate-cli.py list -i grub2-signed=1.202.5
Before: package  grub2-signed  1.202.5+2.12-1ubuntu7.3
After:  (not listed)

With the same fake status file, plus util-linux set back to 2.39.3-9ubuntu6, AptUpdater.find_changes() with the memory GSettings backend still listed bsdutils (and grub-efi-amd64-signed) after the "Ignore the current update" entries were added. After the fix it lists neither.

Not verified: I did not click through the GUI or run a real mintupdate-cli upgrade/automatic upgrade. I did not test on LMDE, so #750 (kernel on LMDE) and #891 (LibreOffice) are matched by the pattern of the bug, not reproduced. Flatpak and Cinnamon spice blacklisting is a separate code path and is unchanged.

Who is affected: anyone who uses "Ignore the current update" on a package whose binary and source versions differ, and anyone with automatic upgrades who exported such an entry. There is one behavior change in mintupdate-cli: if any package of a grouped update (for example a kernel update) matches an entry, the whole update is skipped. Before, only the first package's source name and the last package's version were checked.

To revert, revert this commit. The blacklist format does not change, so existing entries do not need migration.

Thanks @mtwebster for reviewing and merging my earlier fixes (linuxmint/mintsources#285, linuxmint/mintsources#286, linuxmint/mintinstall#518, linuxmint/mintcommon#78).

🤖 Generated with Claude Code

[Amadeus-22]

A few thoughts on the ignore rules, just ideas for later, nothing this PR depends on :)

• Show what an entry matches. In Preferences an entry like grub2-signed=1.202.5 doesn't tell the user that it's a source version, while the update list shows binary versions. Showing the package and version the entry was created from might avoid confusion.
• Automatic upgrades and the ignore list. Today an entry added with "Ignore the current update" only reaches automatic upgrades after the user exports the blacklist again. Maybe adding or removing an entry could offer to re-export it (or show a hint) when automatic upgrades are enabled, so what the user ignores in the GUI is also what the automation skips.
• Grouped kernel updates. With this change, if one package of a grouped update is ignored, the CLI skips the whole update. That felt like the safer choice to me, but I may be missing a case where installing the rest is expected. Happy to change it.

Thanks again for all the recent reviews!

[mtwebster]

Show what an entry matches...

We already group packages by source package, if possible (and individual package names are in the Packages notebook tab). It might be simpler just to mention this in the Blocked packages description text in Preferences.

Automatic upgrades and the ignore list...

Same... add something more descriptive to the button label or change it to Export current blacklist...

Grouped kernel updates...

I think generally updates will refuse anyhow, wanting same-version dependencies.