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.
** Also affects: libnotify (Ubuntu Focal)
Importance: Undecided
Status: New
** Tags added: bitesize
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libnotify in Ubuntu.
https://bugs.launchpad.net/bugs/1961092
Title:
Installing collectd pulls in the X.org stack
Status in libnotify package in Ubuntu:
Fix Committed
Status in libnotify source package in Focal:
New
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libnotify/+bug/1961092/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
