[conspire] People failing to learn about package gatekeeping, part 1

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [conspire] People failing to learn about package  
> gatekeeping, part 1
> Date: Sun, 17 Apr 2022 21:23:41 -0700

> I really do understand the temptation to say "The hell with the distro's
> choice of component versions.  I want the newest stuff."  And, what I'm
> saying is, there are ways for _experienced_ Linux users, if determined

Ah, reminds me of true story ... some fairish number of years back, so I
might be slightly fuzzy on some of the details, but it went about like
this:

At the time where I was working - basically *nix SysAdmin, I was given
various projects - among lots of other typical day-to-day stuff I was
dealing with.  Anyway, as I recall, one of those projects, was to port
a certain Perl application - or more specifically program thereof - from
Solaris to Red Hat.  Others had tried earlier and failed, so ... hey, I
knew Perl, so it got dumped on me.

Well, the crux of the matter was the Perl application code heavily depended
upon two Perl modules - fairly commonly used and reasonably well supported
modules, so that, at least in-and-of-itself wasn't an issue, and it
seemed all the rest of the Perl code ported over quite easily.  So, it
was mostly just down to those two modules.  And ... for the targeted
Red Hat version - and that specific major version being a hard
requirement, due to other dependencies, compatibilities, support
environment, etc.

And, since Red Hat didn't support those needed modules many were
suggesting to just download Perl, core modules and any other needed
modules, compile and install all that ... and done.  And, maybe put it
all under /usr/local so it wouldn't conflict with anything provided by
Red Hat.  Well, I argued that was a quite bad idea - notably on account
of maintenance and security.  On the SysAdmin side where most of the
routine day-to-day maintenance of the operating system would be covered,
there was light to zero coverage for Perl.  So, with such a huge
code base compiled from source and all the relevant modules and such and
installed ... who the heck would maintain that?  Yeah, bad idea - keeping
a large installed Perl base needs frequent updating for bugs and security,
not unlike something like the Linux kernel or a large modern GUI web
browser - significant bugs and security issues will be found and they'll
need to be addressed.  It wasn't particularly feasible to hand off Perl
like that and expect the SysAdmin team to also support and maintain Perl.

So, I went about it a different way.  I got the source for just the two
modules that were needed which Red Hat in no way shape or form provided
or supported ... but a teeny set of code relatively to what was otherwise
being suggested ... so the probability of bugs or security bugs showing up
there was pretty dang low.  So, instead of some huge bunch of Perl
source code, including that of Perl itself and numerous modules, I just
got the source code for the two modules that Red Hat wasn't covering.
And ... I compiled those specifically for the target Red Hat environment,
but/and also having them locally installed in manner where they wouldn't
conflict with anything Red Hat, e.g. under /usr/local or the like, but
using everything else Perl from Red Hat's standard locations and
installed bits.

And, I adjusted the application (program's) code slightly ... it would
use an eval to see if could load the needed modules - and no changes
were made as to where to look for the modules - still used Red Hat's
standard locations.  Only if that failed, would it add the relevant
location(s) under /usr/local (or wherever it was we'd specifically put
it to be appropriate and non-conflicting), so it would then load the
locally prepared version of the modules.  And ... why set it up this way?
Limits the locally one-off maintenance bits to those two modules -
nothing more.  Everything else standard operating system distro stuff.
Additionally, if/when Red Hat ever provided those modules and they were
installed, the application would then use those - so they'd then be
fully supported by Red Hat and the switchover would be automagic.
Essentially forward compatibility for if/when those were available from
Red Hat and put in place.

And ... all this was well documented in the appropriate places ... so
even some SysAdmin unfamiliar with Perl could reasonably understand it
... why it was set up as it was, how it was set up, how to do that again
and how to maintain it ... and even how to check when it may be fully
obsolete and could be dropped (e.g. after Red Hat supplies relevant
modules, such as after some major version upgrade of Red Hat).

Oh, and the slightly more amusing bit.  So ... I did all that over about
2 days within the week, among all the bunches of other customary stuff I
was doing.  And, after I'd completed it and well documented it, etc. a
manager quietly came over to me and told me essentially: "Uhm, ... we'd
earlier brought in a team of three consultants ... for a month ... just
to port that one part that everyone else got stuck on ... and in that
entire month they were unable to come up with *any* solution that worked
... so we let 'em go.".  That had me pretty surprised and shocked ... I
wonder where they came up with those "consultants" ... and who selected
and brought them on for that project.

Anyway, at least one key moral of the story:  As feasible, best not to
stray from what the distro provides and well supports, however, when one
must do so, it's generally best to minimize those deviations to the
extent feasible.