Quoting Simon Hobson (linux@???):

> I too did some checking. From practical experience, one of the ClamAV
> packages (IIRC it's clamd) has a hard dependency on libsystemd0. Using
> dpkg --force-depends to install only that package without having
> libsystemd0 installed results in ... it failing at startup because it
> can't open the library.

Out of curiosity, then, what happens if a file exists and can be opened
but isn't libsystemd0? [Late addendum: The ClamAV developer
_already gave you a better and cleaner solution_, which you haven't
bothered to mention here. Any special reason why you omitted that?
I'll fill that in below, in more late-addendum comments.]

Like, find the tiniest lib with fewest functions you can, and cp it to
/lib/[$ARCH]/libsystemd.so.[version] ?

It would be interesting to find whether this package actually _uses_
anything within libsystemd0 -- which would AFAIK be futile if systemd
isn't present -- or whether it merely (a) checks that a library exists
and is openable (dlopen) or whether (b) it looks up symbols/functions
inside the library (dlsym).

One of the ClamAV upstream developers claims it's in effect (a), saying
'it doesn't do anything if systemd isn't the active init system'.
But you already knew this because the person he said it to was you.
http://lists.clamav.net/pipermail/clamav-users/2015-June/001592.html

[Late addendum: And, oh, wait: The same developer _also_ already told
you that you could make the problem go away by using the 'equivs' trick
-- which I have discussed before.
http://lists.clamav.net/pipermail/clamav-users/2015-June/001601.html
So, basically, you're claiming this is a huge unsolvable problem even
though the developer handed you a solution on a platter, that you're
not bothering to mention here. I see. Meanwhile, let's go on with the
reply as I originally drafted it:]


If the above test works, and I strongly suspect it would, then it's
probably not hard to come up with smoother and more automatable ways.
However, if I _did_ need package clamav (which I don't), _and_ if I were
feeling paranoid about libsystemd0 (which I don't), then I'd just grab
the package source and rebuild it using the debuild utility to omit the
pointless and annoying library dependency and work around the packaging
bullshit. And using debuild is not exactly brain surgery; a link to a
page that walks you through that is part of my OpenRC conversion page.

Please note that I do _not_ assert in any way that it's A Good Thing
that you might be driven to do this (if you are paranoid about
libsystemd0, which I consider a bit irrational). I'd certainly prefer
if you didn't. Fortunately, short of that, rebuilding packages locally
is a pretty easy second way.


> I opened a bug, which was very quickly and quite abusively closed as
> "won't fix", and was also told that "it doesn't work like that" when I
> asked if (especially as it was supposedly only one call they ever made
> on non-systemd systems) why they couldn't do "if exists libsystemd0
> then ..." - something which I now know is possible if the dev/packager
> cares about it.

[Late addendum: The upstream developer's attitude is annoying, but on
the other hand you also didn't tell the whole truth about your
discussion with him, did you, now? I also note in passing that you
portrayed this as a problem with the ClamAV 'package', which is a bit
misleading, as the origin of your problem wasn't with a distro packaging
policy but rather upstream.]


> So after all this, I think I see where some of this division comes
> from ... You *appear* to have been working on the basis that it's a
> "non problem" because the testing you did showed it to be so - for
> your use case.

No, that is _not_ what I said -- and I have said it quite a number of
times and am getting rather tired of having to repeat it.

I perceive it to be not a problem worth spending time on (which is not
the same as 'non problem') because the specific contents of this library
mean it is completely innocuous on a system lacking systemd, in pretty
much exactly the same way that the Kerberos libraries -- pulled in by an
essentially bogus library dependency of package ssh-client on my
Kerberos-less system -- are completely innocuous on a system lacking
Kerberos because of their specific contents.

(The self-parodying bullshit objection of 'In the future, horrible evil
things might be put into the library because of horrible evil package
maintainers colluding with horrible evil upstream and the inability of
the entire Linux community to discover what has happened' has already
been addressed upthread.)


> Some of us have been working on the basis that it *is* a problem
> because our testing shows it to be so - for our use cases.

At the risk of speaking a bit sharply for a moment: Looks to me like
you've also not bothered how to figure out how to do basic
distro-centric system administration. If you'd like to learn a bit of
that, my OpenRC Conversion page has some explanations and links that
should help on all deb-based distros. Following those suggestions
solves problems in pretty much the exact way that merely complaining on
mailing lists does not.

I do sincerely hope the page helps you and others. That's what it's
for. But it only helps if you-generic bother to read it.

> And we've all failed to pick up on this - a bit like the tory of the
> blind men and the elephant

Who's the Tory of the Blind Man and the Elephant? Theresa May? ;->