[ale] CentOS versions increase but package versions kept the same?

Jim Kinney jim.kinney at gmail.com
Thu Aug 19 17:26:47 EDT 2010


Get the version you want as rpm and install with rpm --oldpackage . The
caveat is that the support libs are also compatible. You can also mark
packages to ignore in the yum conf files so updates won't over-wright your
specials.

It can be also done using --relocate to install alternate versions in
/usr/local or /opt if required and some judicious PATH tweaks.

That said, there are large lib differences between 4.x and 5.x. There are
-compat libs that help ease the pain but in reality, it's past time to start
looking at the app dependencies and long term supportability. RHEL 6 is in
beta now so dragging a RHEL 4 application along will start to become a
serious millstone.

Last method (horrid but works) is to lock down a RHEL4 (CentOS) box with the
app on it that isn't going to get upgraded and park that box behind a solid
firewall layer and remove all user accounts other than an admin few. Set
that system up be a remote executer and nothing else. And take everything
off the box that isn't required to run the app.

On Thu, Aug 19, 2010 at 4:32 PM, Jeff Hubbs <jhubbslist at att.net> wrote:

>  This isn't a problem in the Gentoo-land in which I dwell but in
> CentOS, how do people deal with a situation where an app implementation
> depends on specific versions of some number of packages - say, five
> packages at the versions included with 4.6 but one wants to keep those
> same five packages at those same versions but in CentOS 5.5?
>
> Is this CentOS "crazy talk?"  In Gentoo's Portage, you'd just tell
> Portage where to hold those packages' versions and you could just go
> blithely updating other packages in your otherwise versionless Linux
> system indefinitely.  But it seems to me that if you care anything about
> your application, you'd want to give it a platform refresh every once in
> a while.  What I'm asking about is a platform refresh but not for those
> parts of the platform that matter the most - the app's first layer of
> dependencies.
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>



-- 
-- 
James P. Kinney III
I would rather stumble along in freedom than walk effortlessly in chains.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20100819/9450bde8/attachment-0001.html 


More information about the Ale mailing list