Rick Moen <rick@???> wrote:

> 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.

OK, to start with, "sysadmin" is only a small part of ${dayjob} - so many things which full time admins may consider "simple" are not thing that I've ever had the time (and generally need) to deal with. I've never claimed to be a particularly experienced admin, even if my colleagues consider me some sort of guru (everything is relative). Similarly, I don't claim to be a programmer (I can hack a bit of Bash these days, but that's about it) - even though a 1/4 century ago I was writing code commercially (in PL/M 51 if you're interested https://en.wikipedia.org/wiki/PL/M).


But the main thing is, a big part of using a packaged system is to make things "simpler". The moment anyone starts building custom packages then you've tossed a live grenade in the system with a tripwire on the pin. So anyone coming along to admin these systems after me - whether that's because I've moved on or fallen under the proverbial bus - is put in a situation where a simple and innocuous operation could "blow up" the system. OK, so it wouldn't be me that had to worry about that, but personally I consider it unethical to leave booby traps in systems for anyone that comes along to manage it after me. Either I fudge with version numbers so that an apt-get upgrade will never try and replace my customer package (leaving someone scratching their head as to why), or I don't and an apt-get upgrade does strange things (most likely failing with misleading errors due to pinning and it not being able to satisfy dependencies).

And I can absolutely 100% guarantee that anyone else in the company that might have to take over is a looooooooong way off the skillset for things like building customer packages, and I do mean a veeeeery loooooong way off that. That, for the most part, is why I've gone to great lengths to only use distro packaged software on the systems - even when it would have been easier at times (thinking more about CGI stuff rather than compiled programs) to grab the upstream and manually install it.

I did look at equivs - but the information (or links) presented to me then implied something very different to the "simple" stuff that's been presented (IIRC) in this thread. Then (from what I vaguely recall reading) I was under the impression that equivs involved more than just a "pretend that this package is installed" instruction to apt as the recent reference here suggested to me. But from empirical observation, just telling apt to "pretend libsystemd0 is installed even though it isn't" won't work when the program "blows up" during startup when the linker can't open a library it's been told is needed by this program.


So look at it from my PoV.
I've been told that I could build an equivs package to provide the library and empty functions to keep the program happy - and I've been told that equivs is just a short recipe to apt that makes it "pretend" the library is installed.
I've been told that no you can't just open the library if it exists, and I've been told that it's really easy to do.
I've been told that equivs (as in the latter) will let a program start even if the library isn't there, and I've shown by experiment that the program "blows up" at start if the library is missing.
Confused :-/


Incidentally, after the exchange referred to, someone contacted me offlist with the comment "if that's the customer service department, I'd hate to see the complaints department" - so it would appear at one other person sees my PoV.