Quoting fsmithred (fsmithred@???):

> Yeah, that was me, and it was based on partially incorrect testing. I set
> the permissions to 000 on the wrong target. The test with the dummy
> libsystemd0 package worked great to fulfill the package dependency and
> allowed me to install gvfs, but gvfs wouldn't make the drive icons.
>
> I repeated the permissions test on the correct target with the real
> libsystemd (chmod 000 /lib/i386-linux-gnu/libsystemd.so.0.3.1)
> and I got the same result. If libsystemd is not readable, gvfs won't show
> the drive icons.

Let me take a moment to thank you for going to the effort. I respect
seeking meaningful data rather than just posting advocacy, so I
appreciate that. No worries about the mistake; if I had to pay a penny
for every technical mistake or erroneous characterisation I made, I'd be
poor indeed.

> So yes, I agree with you that it looks like it's gvfs that's doing
> something, and the something it's probably doing is using code in
> libsystemd. Or maybe it's telling something else to do it. Either way, it
> looks like libsystemd is passively providing code for something else to
> use. If the code is being used by some program, that's doing something.
>
> Is there another interpretation of these results?

My guess is and was that gfvs merely checks for existence/nonexistence
of a function inside gvfs, and does disable/enable based on what it finds.

If you ever feel like trying a less-brittle Desktop Environment ('DE'),
consider LXQt or Enlightenment. (A more-radical step would be no DE at
all, which is my personal preference. To me, a DE is a goulash of apps I
want with ones I don't, so I see no value in the ensemble. But as
Prince Orlovsky said in 'Die Fledermaus', Chacun à son goût:
https://www.youtube.com/watch?v=l6uEmtn56M0 )

-- 
Cheers,                                       "My opinions may have changed, 
Rick Moen                                     but not the fact that I'm right."
rick@???                                       -- Ashleigh Brilliant
McQ! (4x80)