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

[Adam Borowski]

On Sun, Jun 09, 2019 at 12:22:57AM +0100, Simon McVittie wrote:
> On Fri, 02 Sep 2016 at 06:42:19 +0200, Adam Borowski wrote:
> > After today's upgrade of libglib2.0-0, I get every single entry of fstab,
> > even /proc, show up as a desktop item.  This is with xfce.
> > 
> > Reproducible on a freshly installed system; you just get 2 entries
> > ("Filesystem root" and "cdrom0") as fresh fstab is rather empty.
> > 
> > No gvfs installed, so none of those should show up.
> 
> It appears that gvfs *not* being installed is a key part of this, at
> least in buster. This probably indicates that this is a limitation of
> the fallback GUnixVolumeMonitor in GLib, which is used when a better
> plugin (like gvfs' GVfsUDisks2VolumeMonitor) is not present or has been
> disabled.

Great, thanks for debugging this!

I confirm: installing gvfs reduces the set of icons to just "Trash",
"File System" and "Home", at least on this dingy Pinebook.
 
> GLib and gvfs are separate components to avoid circular dependencies
> (for instance if gvfs was integrated into GLib, then udisks2 couldn't
> use GLib without a circular dependency) but for desktop use-cases,
> I'm fairly sure their overlapping sets of upstream maintainers would say
> that GUnixVolumeMonitor is only intended as a fallback implementation,
> and is not designed to have the full UI heuristics.

Or it might be better to not show any filesystem icons at all -- predefined
ones are of limited use anyway.  But I'm not a clicky-clicky user, and my
personal reason to uninstall gvfs was that automounting USB sticks and SD
cards is harmful for me: for transferring files between computers you have
the network, USB sticks are for boot media, SD cards tend to have some ARMy
install on them.  Other gvfs features are also of little use to me.  Oh, and
I don't want a modem bleat about its Windows drivers it has on an USB
storage subdevice.

For most of other users with this problem, I guess it's mostly an issue
with overblown Recommends: either people intentionally want to get rid of
something, or gvfs is collaterral damage from users lashing back at
Recommends gone amok and thus missing them even when they make sense.

> File managers (and implementations of icons on the desktop, if separate)
> should probably have a Depends, Recommends or Suggests on gvfs to indicate
> this. XFCE's thunar Recommends gvfs and doesn't mention gvfs-backends,
> which seems appropriate for a desktop environment intended to be
> lightweight; GNOME's nautilus Depends on gvfs and Recommends the more
> elaborate gvfs-backends, which seems appropriate for a more fully-featured
> desktop.

Sounds right.

> Perhps libglib2.0-0 should also have a Suggests on gvfs (and
> glib-networking, which has a similar role for TLS and network proxy
> support), but since that would be circular, I'd be concerned that
> it might prevent apt frontends from proposing libglib2.0-0 and gvfs
> for autoremoval when the last package that depends on them is removed.
> A Recommends definitely seems too strong, because GVolumeMonitor is only
> a small part of GLib.

So you actually care about Recommends being too strong?  Maintainers saying
that is new to me. :)

> If you don't want the more complicated gvfs backends, like the ones for
> network protocols and MTP devices, I would suggest installing gvfs and
> its required gvfs-daemons package, but not installing gvfs-backends.

Automounting MTP is actually much better than doing so for USB devices:
the other side must be an already working machine, and the protocol is
drastically simpler than any on-disk filesystems.  Mounting an untrusted
filesystem is an easy ring0 security exploit.

> Steps to reproduce:
[lots of stuff about the API]

While your explanations sound plausible, I don't know the glib/gvfs API well
enough to countercheck you.  Here's the output of your script on the
Pinebook I'm sitting at, with and without gvfs installed -- but as it meets
what you said, you probably don't need to even look at it.

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?  It'd meet at least my preferences --
not sure about other folks who elect to not install gvfs.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ NADIE anticipa la inquisición de españa!
⠈⠳⣄⠀⠀⠀⠀
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pinebook-with-gvfs.json
Type: application/json
Size: 16196 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/attachments/20190609/4211ebea/attachment-0002.json>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pinebook-wo-gvfs.json
Type: application/json
Size: 16401 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/attachments/20190609/4211ebea/attachment-0003.json>