:: Re: [DNG] Why Debian 8 Pinning is (…
Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Steve Litt
Ημερομηνία:  
Προς: dng
Αντικείμενο: Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
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.

SteveT