Quoting Simon Hobson (linux@???):

> Rick Moen <rick@???> wrote:
>
> > That doesn't logically follow. My guesstimate is that some GNOME
> > plumbing is checking for some library function before it offers
> > the user 'removable drives [...] on the desktop'. For libsystemd0
> > library functions to _do_ anything reportedly requires systemd be
> > present to be reached below the library, i.e., the lib is just interface
> > glue.
>
> That is another possibility.

All my reading suggests it's exactly the situation. Mind you, I haven't
looked into the matter deeply, as my attention has been needed on
countless other things.

> However, for that to be the case then they must be doing the "check if
> X exists before calling X" technique that I believe must be possible
> (simply because so many pieces of software have soft dependencies on
> optional modules).
>
> So if they are doing that with something in systemd itself, there is
> no reason not to do it with libsystemd0.

Programmers are lazy. ;->

> But either way, even if libsystemd itself doesn't do (present tense) anything,

I have high confidence I'd have heard, were that the case.

> ...I have zero trust that it will remain that way.

I have high confidence I would hear, were that newly the case.

And then I'd remove the thing and substitute an equivs entry, about five
minutes after I heard.

Remember that bit I posted about how /usr/bin/ssh makes dynamic library
calls to sonames of two Kerberos libraries, even on the overwhelming
majority of systems that do not implement Kerberos? That was one nearby
example from my own system, from among _countless others_ I could have
pointed to. It's not a dire conspiracy; it's just regular, somewhat
overly inclusive default practices common among distro packagers. I'm
not going to become actively paranoid about libgssapi_krb5.so.2 and
libkrb5.so.3 packagers, nor about upstream Kerberos5 coders, just
because either could 'shift some code into libkrb5.so.3'.

Note that, even _if_ I thought upstream Kerberos5 coders were engaged in
a sinister conspiracy to take over all Linux distributions and
jeopardise our precious bodily fluids, I would not easily distrust
_both_ upstream Kerberos5 coders and distro Kerberos library (package)
maintainers who are, after all, gatekeepers. Maybe you have time for
that degree of highly selective paranoia, but I don't. I have to deal
with real threats.

But in the bizarre and (I thin) unlikely event of that being noneteless
the case, I'm confident I'd hear about it promptly, and I'd fix it
promptly. ('This is Unix. Stop acting so helpless.' -- D.J.
Bernstein.)

'Trust' in the sense you use the word just isn't in that.