[PLUG] Are dependences obsolete?

[Tim]

Yeah, it seems to me that running a VM for legacy incompatible stuff
is far easier.

I typically stay away from distros that are very task-specific.  While
it's convenient and all to have a certain set of software installed
and configured by default, the folks managing those distros have very
limited resources and don't maintain their package tree very well.  So
you end up with a lot of package conflicts on simple things when the
upstream updates something or you want to add something that expects a
better maintained base distro.  Most of the time, the exact same
software that comes by default on a task-specific distro can be
installed without too much trouble on a general purpose distro, with
the added bonus that most dependency issues are better dealt with.
Failing that, just use VMs to avoid the dependency headaches.

HTH,
tim


On Fri, Mar 21, 2014 at 09:05:33AM -0700, Darren Couch wrote:
> That seems like a great reason to run a virtual machine and sandbox a more
> modern linux to run those specific apps.
> 
> 
> On Thu, Mar 20, 2014 at 8:58 PM, Keith Lofstrom <keithl at gate.kl-ic.com>wrote:
> 
> > 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
> > _______________________________________________
> > PLUG mailing list
> > PLUG at lists.pdxlinux.org
> > http://lists.pdxlinux.org/mailman/listinfo/plug
> >
> 
> 
> 
> -- 
> Darren R. Couch
> dcouch at gmail.com
> _______________________________________________
> PLUG mailing list
> PLUG at lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug