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

[Jeremy Bicha]

On Sat, Nov 8, 2025 at 3:03 AM Raphaël Halimi <raphael.halimi at gmail.com> wrote:
> Le 04/11/2025 à 13:41, Jeremy Bicha a écrit :
> > I'm downgrading the severity since my initial thinking is that this is
> > somewhat of a feature request and also a description of unexpected
> > behavior but not necessarily wrong behavior from how gnome-software is
> > designed to work. Also, Debian appears to be changing the autoremoval
> > rules which makes RC level bugs have far-reaching effects.
>
> IMHO the fact that an APT frontend **silently** causes other package
> removal, by just advertising users to "reboot and install updates",
> deserves a much greater severity than "normal".
>
> This is not specific to my case (a home package which, among other
> things, holds another package) ; think of huge package sets (like
> LibreOffice for example) which don't all land in the archive at the same
> time (this happens regularly in unstable and backports, I can't be sure
> but I think it could happen in stable too).
>
> Downgrading this bug's severity just to avoid autoremoval seems to me
> like sweeping the problem under the rug.

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.

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.

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

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.)

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.

> > Maybe apt-mark hold would have worked?
>
> Yes, it would. But how to distribute this file to an entire IT fleet,
> quickly enough so that the update of Firefox is not held 24-48h after
> the file was distributed ? Playing with package dependencies makes more
> sense, especially if the default behavior of APT (and the majority of
> its frontends) is to do a normal upgrade, which **can't** remove packages.

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

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.

Thank you,
Jeremy Bícha