Bug#836355: libglib2.0-0: makes all entries of fstab show up as desktop items

[Simon McVittie]

On Sun, 09 Jun 2019 at 18:21:10 +0200, Adam Borowski wrote:
> my personal reason to uninstall gvfs was that automounting USB sticks and SD
> cards is harmful for me

gvfs doesn't do this, so preventing automounting by removing gvfs is not
reliable (at best, you're only preventing automounting accidentally,
by the fallback GUnixMountMonitor not being sufficiently complete to
signal new devices appearing). Whatever higher-level component responds
to new drives/volumes appearing by mounting them should have a way to
disable that behaviour.

For example, in current GNOME automount is done by gnome-shell, in GNOME
Flashback it's done by the gnome-flashback service, and in older versions
of both it was part of gnome-settings-daemon, all of which share a dconf
setting "/org/gnome/desktop/media-handling/automount" which can turn it
off. In XFCE's thunar, as far as I can tell, the thunar-volman package
is responsible for this and has two settings "/automount-drives/enabled"
and "/automount-drives/enabled" in the xfconf framework (or removing
thunar-volman would probably also work).

There are also UDISKS_AUTO and UDISKS_IGNORE udev properties
that you can set on devices via udev rules, which higher-level
components are meant to use as a hint that this particular device
is not to be mounted automatically, or should not appear at all,
respectively. In GLib with gvfs, UDISKS_AUTO gets propagated up through
the g_volume_should_automount() method.

> So you actually care about Recommends being too strong?

Of course. Recommends and Suggests are a trade-off between a hard
dependency and no relationship, and maintainers should choose carefully
case-by-case whether a related package that is not strictly essential
should be a Depends, Recommends, Suggests, or not represented in dpkg
metadata. Whatever we choose, not everyone is going to like the decision,
but a decision needs to be made anyway - preferably one that balances
the partially-conflicting goals of making default installations as good
as possible for as many people as possible, having enough flexibility
to allow for unusual installations, and preventing broken situations
from being installable.

I can understand the appeal of a more minimal system, and I turn off
some selected Recommends myself, but I don't think globally disabling
installation of Recommends and expecting a system as complex as a full
desktop environment to have all of its intended behaviours is sustainable.
If users demand full functionality with Recommends disabled, one logical
but ironic course of action available to maintainers is to use fewer
Recommends and more Depends, which of course leads to the exact opposite
of what users who turn off Recommends were presumably aiming for.

> On the other hand, I have serious doubts if fixing the fallback mechanism is
> a good use for your time.  Perhaps it'd be better for it to return "nothing
> removable" if gvfs is not installed?

I don't think falling back to "there are no devices, no volumes and no
mounts" is really the intent of the API, but if you want to propose this
upstream as the fallback behaviour, go ahead. I am not going to forward
that request upstream myself, because proposing changes that I don't
personally want and can't justify well will tend to get them rejected,
and I don't want to sabotage the opportunity for someone who wants this
more than I do to justify it better than I could.

    smcv