Rick Moen <r...@linuxmafia.com> 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.
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
