Dear developer,

I'm not sure if this bug should filed against GNOME Software or
PackageKit, but IIUC since the latter is only an interface which dumbly
does what other software ask it to do, I think the real culprit here is
GNOME Software (which "prepared" the atomic operation), despite what the
logs say.i If you think otherwise, please reassign to packagekit 1.3.1-1.

Some time ago one, of my users complained that he couldn't browse the
web anymore, and found that the proxy settings in Firefox were gone.
After I looked into it, I found that Firefox lost its whole
`policies.json` file, which is provided by a home-made package (and
configures the proxy settings).

The problem was that this package has a versioned dependency against
Firefox ESR. We do this in order to control when our users will switch
to a new ESR version. I was confident that this would hold Firefox ESR
upgrades until we decided to allow them, since `unattended-upgrades` is
not supposed to remove packages, but it seems that GNOME Software
doesn't care about that: to install the new version of `firefox-esr`
(presented as a security update, OK, but still), it carelessly removed
my package (and one of its reverse dependencies), as shown in the logs:
-----%<-----
Start-Date: 2025-09-19  15:42:12
Commandline: packagekit role='update-packages'
Upgrade: firefox-esr-l10n-fr:amd64 (128.14.0esr-1~deb13u1,
140.3.0esr-1~deb13u1), firefox-esr:amd64 (128.14.0esr-1~deb13u1,
140.3.0esr-1~deb13u1)
Remove: mycompany-desktop:amd64 (0.5), mycompany-firefox-esr:amd64 (0.6)
End-Date: 2025-09-19  15:42:46
----->%-----

And it did it again with Thunderbird some days later:

-----%<-----
Start-Date: 2025-09-30  15:09:54
Commandline: packagekit role='update-packages'
Upgrade: thunderbird:amd64 (1:128.14.0esr-1~deb13u1,
1:140.3.0esr-1~deb13u1), thunderbird-l10n-fr:amd64
(1:128.14.0esr-1~deb13u1, 1:140.3.0esr-1~deb13u1)
Remove: mycompany-thunderbird:amd64 (0.12)
End-Date: 2025-09-30  15:09:57
----->%-----

The user doesn't remember much; he told me that he thinks he received a
GNOME notification saying that an update was available, and clicked on
it. He doesn't remember if the upgrade was done while the system was
running or if GNOME asked to reboot the machine and the upgrade was done
offline, but IMHO this is irrelevant: a simple package upgrade should
not remove packages.

Note: of course our users don't have administrator rights on their
machines and normally can't install packages by themselves with tools
like APT or GNOME software. This was an automatic upgrade seemingly
initiated by GNOME Software and handled by PackageKit, the user just
accepted what the UI suggested.

In the meantime I created an equiv package to remove `gnome-software`
from all machines (since anyway users are not allowed to install
packages with it), and let `unattended-upgrades` manage upgrades. Maybe
`gnome-software` should not be a hard dependency of `gnome-core`, but
merely a recommends.

Regards,

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.

Maybe apt-mark hold would have worked?

If you don't want your users installing apps, it makes sense to me for
you to remove gnome-software like you did. Maybe you need to also lock
down PackageKit with a PolicyKit rule.

gnome-core is generally just mirroring the package choices of GNOME upstream.

There have been some requests over the years to create a more minimal
GNOME metapackage for Debian, but it hasn't been done yet. You can
follow https://bugs.debian.org/1089002 for this request.

Thank you,
Jeremy Bícha

Hi,

Thanks for your answer.

Le 04/11/2025 à 13:41, Jeremy Bicha a écrit :

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.

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.

After what happened, I prefer to remove it completely. Apart of
gnome-software, the only thing needing it is gstreamer1.0-packagekit
(which I also don't want). Fortunately, our Linux workstation project is
still in its testing phase, and only one of our testers was impacted
(i.e. used his machine enough in the time window needed for the Firefox
upgrade to land on it). I can't imagine the catastrophe if it happened
to 5000 users, which suddenly couldn't browse the web...

Yes, but the distinction between Depends and Recommends is specific to
Debian, isn't it ? Upstream just tell which programs are parts of GNOME,
but Debian maintainers have the final word on what's really needed and
what's dispensable. Why not make it a Recommends, like
gnome-remote-desktop, gnome-tour, gnome-user-share, gnome-initial-setup,
etc which I'm sure are advertised by upstream as part of GNOME ? This
would greatly facilitate things for administrators in charge of IT fleets.

Regards,

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.

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

Hi,

Thank you for your answer.

Le 10/11/2025 à 23:58, Jeremy Bicha a écrit :

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.

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

Will do.

I wouldn't mind, provided that it can't remove packages under stable
(see 1).
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.
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...

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,