Installing collectd pulls in the X.org stack

Bug #1961092 reported by Robie Basak
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libnotify (Ubuntu)
Fix Released
Medium
Robie Basak
Focal
New
Undecided
Unassigned

Bug Description

On Ubuntu Server, "apt install collectd" pulls in huge parts of the X.org stack, which is generally undesirable. This was brought up in #ubuntu-server earlier. Workaround: use --no-install-recommends

This seems to be due to collectd -> libnotify4 -> gnome-shell -> ... chain. This appears to have been made worse in an Ubuntu delta regarding gnome-shell. Debian's packaging still recommends notification-daemon which still pulls in quite a lot.

It seems odd to me that a lib* package would recommend anything, since they tend to be leaves in the dependency tree apart from other lib* packages. Further it's difficult to avoid depending on a lib* package for optional functionality, so it ends up being inconvenient as demonstrated in this use case.

Wouldn't it be better for the desktop environment to recommend something that can receive notifications in order for the dependency system to do the sensible thing by default, instead of using Recommends from the notification sending end? Then headless systems wouldn't end up pulling in a "head" via Recommends.

So my suggestion is to drop the Recommends from libnotify4 altogether, including in Debian.

From a policy perspective, Recommends is defined as "The Recommends field should list packages that would be found together with this one in all but unusual installations". I think the headless case is a common installation, not an unusual one, so that disqualifies libnotify4 anyway.

Tags: bitesize
Revision history for this message
Robie Basak (racb) wrote :

Adding Seb for comment please.

Changed in libnotify (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
description: updated
Revision history for this message
Robie Basak (racb) wrote :

FTR, Seb gave me an ack to drop the Recommends to a Suggests in #ubuntu-devel last night, so I'm going to go ahead and upload.

Changed in libnotify (Ubuntu):
status: Triaged → In Progress
assignee: nobody → Robie Basak (racb)
Robie Basak (racb)
Changed in libnotify (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Robie Basak (racb) wrote (last edit ):

This was originally reported against 20.04. I haven't validated that, but that report seems likely to be correct to me. It's worth considering an SRU for 20.04 too, but I'm focused elsewhere now. If someone would like to drive an SRU, then please do!

Things to consider for an SRU:

Are we sure that this doesn't regress desktop in any way? For example, does the desktop seed rely on this Recommends to pull in parts of the notification stack? It might be worth waiting for Jammy to settle to help determine that.

Are any server users relying on the Recommends in any way to pull in other dependencies? For example, if in automation a server deployment is directly installing collectd but then relying on the Recommend to pull in some other package, then that package wouldn't get installed after an SRU and therefore regress that deployment automation. This is probably OK, but worth pointing out.

tags: added: bitesize
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libnotify - 0.7.9-3ubuntu5

---------------
libnotify (0.7.9-3ubuntu5) jammy; urgency=medium

  * Drop libnotify4 Recommends on "gnome-shell | notification-daemon" to
    Suggests so that headless packages with notification capability
    don't pull in parts of the desktop stack (LP: #1961092).

 -- Robie Basak <email address hidden> Tue, 05 Apr 2022 13:34:40 +0100

Changed in libnotify (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.