Hi,
Thanks for your answer.
Le 04/11/2025 à 13:41, Jeremy Bicha a écrit :
Control: severity -1 normal
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.
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.
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.
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.
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...
gnome-core is generally just mirroring the package choices of GNOME upstream.
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,
--
Raphaël Halimi
