Quoting Simon Hobson (li...@thehobsons.co.uk): > 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? ;-> _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng