| 2022-02-16 16:30:21 |
Robie Basak |
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 of recommends. 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. |
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. |
|
