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 kei...@keithl.com _______________________________________________ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug