Re: Too many Recommends (in particular on mail-transport-agent)
- Date: Tue, 6 Jun 2017 17:38:47 +0100
- From: Simon McVittie <smcv@xxxxxxxxxx>
- Subject: Re: Too many Recommends (in particular on mail-transport-agent)
On Tue, 06 Jun 2017 at 09:06:46 -0700, Russ Allbery wrote:
> Adam Borowski <kilobyte@xxxxxxxxxx> writes:
> > More seriously, though, let's go through the list of 94 unsatisfied ones
> > on my desktop; the list below is transposed to collate recommendees.
> And what happens here is, I think, typical: any one person often thinks
> choices of recommends make no sense, but a broader perspective provides
> quite a bit of justification.
Adam, if you want the size of a typical system to be reduced, I don't
think the approach you've taken here is going to be the most effective.
Making maintainers angry by dismissing software as obsolete, pointless or
similar - even if it is true! - is not usually going to make them more
likely to do what you say.
I can see that you value minimal systems. That's fine, but bear in mind
that you are experienced enough to make those systems work, and
hopefully also experienced enough to avoid making them insecure while
making them work; and relately, you are experienced enough to use a
package manager to get the system the way you want it. Not everyone is.
If there is a best set of Recommends for inexperienced users, and a
best set of Recommends for experienced users who value minimality, then
we should err in the direction of supporting the inexperienced users,
precisely because those are the people least likely to be able to use
package managers to get a particular feature that they want. If some
"wasted" disk space on typical systems is the price we pay for a feature
working on the first attempt, rather than an inexperienced user giving
up before they can get that feature to work, or simply not knowing that
the feature is even possible, then that seems a worthwhile price to pay.
You are already making a cost/benefit trade-off by using Debian, a
relatively complete binary distribution. You could get a more minimal
system by disabling more things at compile time with something like
Gentoo's USE flags, but presumably you've considered that and decided
that the benefits of using a binary distribution outweigh the costs.
(Insert the usual observation here about how a typical Debian system
has both libapparmor and libselinux, despite it being literally
impossible for both to be useful at the same time...)
> > libgnomeui-0: xscreensaver
> > * BAD: Gnome users won't run xscreensaver
> What? The hell they won't.
This one *is* obsolete though - not xscreensaver, but libgnomeui-0.
libgnome and libgnomeui were deprecated sometime during the GNOME 2
era, and for stretch the GNOME team has finally managed to exclude them
from a default desktop installation (task-gnome-desktop), but
unfortunately there are still more than 50 packages using them.
The GNOME team would be delighted to see that number go down.
The libgnome* libraries help you to integrate with a desktop from around
10 years ago that we no longer ship, and are not part of modern GNOME;
their high-level functionality has mostly been superseded by code in
GLib and GTK+.
During the time that libgnome was a recommended thing to use,
I think xscreensaver was used by default in a complete GNOME
installation. It was subsequently replaced by gnome-screensaver,
which was in turn replaced by the screen lock included in GNOME Shell
during the transition to GNOME 3. It is certainly possible to construct
your own GNOME-based desktop environment that includes xscreensaver by
fitting together the pieces yourself (similar to how the openbox-*-session
packages provide openbox-based variants of several desktop environments),
but that isn't the complete GNOME environment any more than