On 2016-07-28 10:16, Steve Litt wrote:
> On Thu, 28 Jul 2016 00:48:12 -0700
> Rick Moen <rick@???> wrote:
>
>> 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? ;->
>
> Which brings us full circle. Simon doesn't want to keep playing these
> games, wondering what kind of workaround he'll need next, as Lennart
> decides to subsume yet another Linux functionality, or Debian's "DDs"
> make yet another poor decision on dependencies. So he chose to go with
> the fork.
>
> I don't have the tech chops to know all the various ways Lennart can
> screw up my life, nor do I have the technical chops to know (without
> huge experimentation) how to work around Lennart's latest incursion. I
> know the incursions will keep on coming, so why in the world would I
> subject myself to them? Therefore, to my limited ability, I help the
> guys who made the fork, and recommend the fork to those not compatible
> with Void or Funtoo or PC-BSD (and most Linux users aren't compatible
> with those).
>
> And then there's this: I don't know anything about Simon's feelings,
> but Debian's actions of 2014 disgust me. For me, continuing to use
> Debian is an impossibility. Stupid technology comes and goes, but
> betrayal is forever. They got arrogant, they got forked, and the
> resulting Devuan community is one of the best I've ever belonged to.

+1


--
Stop slacking you lazy bum!