[PLUG] Are dependences obsolete?

Keith Lofstrom keithl at gate.kl-ic.com
Fri Mar 21 03:58:37 UTC 2014


On Tue, Mar 18, 2014 at 04:43:53PM -0700, Tim wrote:
> Your software distribution does you a grand service by managing this
> for you.  Use a distro that does it right, buy into it and use their
> framework, and many of the headaches you describe become minor.

On Wed, Mar 19, 2014 at 08:31:38AM -0700, Paul Heinlein wrote:
> For example, if there were a vulnerability in libcrypt, roughly 300 
> binaries on one of my CentOS 6 servers would have to be rebuilt, 
> repackaged, and reinstalled.

Wise words, thanks for that.  I suppose what I should want is
a "multilibrary" wrapper and package updater for new packages.

I run a Red Hat Enterprise clone, Scientific Linux 6.5 .  It is
stodgy (equivalent to Fedora 12, a 4 year old base kernel) - but
it will get security updates until 2023, supported by Fermilabs
even if Red Hat goes away (or worse, gets bought by Larry
Ellison).  The problem is, almost all recent third party not-in-
the-standard-distro packages want later major revs of libraries
with new features; I can't compile or run those because the
dependencies collide.

So what if I could run different families of programs with
different runtime loaders, which looks at the program's requests
for libraries and other runtime requirements and pulls them from
someplace besides the mainline /usr/lib ?  This would require
more disk space, more backup time and storage, and many nightly
update processes, but it would mean that old stuff that is
difficult to migrate wouldn't have to, and I would never see
dependency conflicts when loading a new package.

So, I might be running SL6.5, Fedora 20, and Ubuntu 14.04 
packages all on the same machine, and migrating binaries from
older to newer distros gradually, as new very long term support
versions become available.  New machines could be installed with
the latest SL6.5 (or SL7.1 or 8.1 when those become available)
with similar linker/wrappers backwards to older libraries.

Yes, this might leave some security holes in some of the obscure
web-facing components, but for those of us with a gigantic
/usr/local/bin and ~/bin , not being able to easily keep old
capabilities represents a larger threat to productivity. 

Keith

-- 
Keith Lofstrom          keithl at keithl.com



More information about the PLUG mailing list