Bug#1117973: gnome-software: removes packages during upgrades

[Raphaël Halimi]

Hi,

Thank you for your answer.

Le 10/11/2025 à 23:58, Jeremy Bicha a écrit :
> I think this issue is more complicated because there are multiple
> concerns here besides the system administrator configuration issue.
> 
> 1. Should the gnome-software app allow removals? Yes, I believe this
> is required. For instance, in Unstable, mpv was rebuilt this weekend
> so that it depends on libdisplay-info3 instead of libdisplay-info2.
> libdisplay-info2 should be removed. In some cases, package removal is
> required to finish the upgrade or allow installing a particular app.
> 
> Because "removing packages during upgrade" was the subject line of the
> bug, I think we could close this bug. Actually, this bug might be the
> opposite of https://bugs.debian.org/1041553 which suggests that GNOME
> Software's behavior did change between Debian 12 and Debian 13.

For testing/unstable, I would tend to agree, gnome-software should be 
able to remove packages, **provided it's able to tell what will be 
removed before you validate the upgrade** (which remains to be checked).

For stable, no, it should not.

Ideally, this should be configurable through some kind of system-wide 
switch.

> 2. Should there be better system administrator documentation about how
> to hold back a particular package? Yes! I don't know what package to
> file this bug against though.

I know about dpkg holds (through dpkg --set-selections or apt-mark), and 
also about apt pinning, but more details below.

> 3. Should the 'gnome-core' metapackage depend on gnome-software? You
> can file a bug there and we can discuss it.

Will do.

> 4. Should gnome-software be configured for offline upgrades by
> default? When I looked a few years ago, I did not see an easy way to
> patch gnome-software to work like this. You're welcome to file a bug
> for this. (I guess you didn't mention this, but I find
> gnome-software's behavior annoying here and it conflicts with how
> unattended-upgrades is set up in Debian.)

I wouldn't mind, provided that it can't remove packages under stable 
(see 1).

> 5. Should gnome-software allow upgrading .deb apps by default by
> non-admins? I looked into this more closely and reported
> https://bugs.debian.org/1120489 Thank you for alerting us to this
> issue.

In fact, I don't mind this. unattended-upgrades does it in the 
background, so why not let users trigger it anyway (in fact, I even 
added support for upgrade mode in our custom Plymouth theme specifically 
for this case).

The real cherry on the cake would be for unattended-upgrades to support 
offline upgrades (as opposed to upgrades during shutdown, which needs to 
increase systemd's "InhibitDelayMaxSec") and replace gnome-software's 
offline upgrades completely.

Note: in fact, having both upgrade systems on a system is quite 
confusing. At the very beginning, I believed that those offline upgrades 
were triggered by unattended-upgrades, before I understood 
gnome-software's role in them, and that unattended-upgrades' 
"InstallOnShutdown" option was a totally different process.

> Apt pinning is another strategy you should look into. That can be
> distributed as a conf file.

That's what I tried to explain in my previous e-mail: distributing this 
file through a package would delay updates, possibly several days.

Let's suppose I provide the APT pinning file in a package. When we deem 
the new Firefox won't introduce compatibility issues, and decide to 
allow the upgrade, we would provide a new version of this file, but it 
won't be taken into account by APT, and thus, Firefox won't be upgraded, 
until the next upgrade cycle.

Now let's see the default APT timers settings:

-----%<-----
# /usr/lib/systemd/system/apt-daily.timer
[Timer]
OnCalendar=*-*-* 6,18:00
RandomizedDelaySec=12h

# /usr/lib/systemd/system/apt-daily-upgrade.timer
[Timer]
OnCalendar=*-*-* 6:00
RandomizedDelaySec=60m
----->%-----

Meaning, two "apt update" per day, at 06:00 and 18:00 (or at boot), but 
randomized in a 12h span, and one "apt upgrade" per day, at 06:00 (or at 
boot), randomized in a 60 minutes span.

In practice, provided a user turns on his/her machine every day some 
time between 09:00 and 17:00, this doesn't even guarantee that one 
update/upgrade cycle will happen everyday. And, with the APT pin file 
distributed through a package, this delay would be doubled.

I know I can provide systemd drop-ins to decrease or even remove the 
randomized delay, but even in that case, Firefox would be upgraded two 
days (or even more) after we release a new version of the package 
providing the APT pin file.

Playing with versioned dependencies was TTBOMK my best option, but, 
little did I know that gnome-software would carelessly remove packages 
to install upgrades...

> I agree that for your environment it makes sense to remove the
> gnome-software app if you don't want your users to be able to install
> or uninstall apps. If you were willing to allow your users to install
> Flatpak apps, you could install gnome-software-plugin-flatpak and
> uninstall gnome-software-plugin-deb. This is a new option in Debian
> 13, to allow uninstalling the deb plugin but keep gnome-software
> installed for other uses. Flatpaks can be installed per-user or
> system-wide.

Thanks for the suggestion, but in hindsight, removing it completely is 
still the best thing to do. Users wouldn't understand why they have 
access to an app catalog if they're not allowed to install or remove 
packages. In fact I should have removed it way before this incident (but 
as I mentioned earlier, our Linux workstation project is still in its 
testing phase; I had that matter in mind but I delayed my decision; this 
incident only rushed it, for the best).

As I mentioned in my answer to 5/, unattended-upgrades supporting 
offline updates, and users having a nice text displayed by Plymouth when 
upgrades are performed, would be great.

Regards,

-- 
Raphaël Halimi