[CentOS] Karanbir CentOS REPO - Breakability?

Phil Schaffner Philip.R.Schaffner at NASA.GOV
Fri Mar 10 13:36:14 UTC 2006

On Fri, 2006-03-10 at 12:43 +0100, Dag Wieers wrote:
> On Fri, 10 Mar 2006, Johnny Hughes wrote:
> > One thing I want to make clear here [this is for the list and not just
> > Phil :)] is that I would not run a "yum update" with any 3rd party repo
> > enabled ... ever.

Agree for a production machine, but on my home mixed MythTV
client/server systems that were already somewhat broken by mixing
assorted repo packages by the methods you described so well, I thought
it was worth a shot.  The exercise I just went through doing a fresh
install on one system and falling back to a backup on the other to clean
up the mess, after wasting a few hours trying to manually
upgrade/downgrade packages to get yum/yumex/smart working again,
certainly illustrates your points.

[Somewhat OT:  If ATrpms packages weren't such a PITA to rebuild due to
unreleased rpm macros, I'd have a go at doing a CentOS rebuild of MythTV
and deps from SRPMS.  Anybody got any sage advice to offer on that

> > Dag does a great job with his repo (I use parts of it on almost every
> > single machine I install), as does Karanbir, Dries and Axel.
> > 
> > However ...  every single one of these repos (or any other 3rd party
> > repo, for that matter) has the potential to break your install.
> I have stated many times that for production usage I would not recommend 
> to enable my repo by default and automatically install updates. Even 
> though everything runs fine and has been tested by yourself at one point 
> in time, updates might break. And if your business relies on this, I 
> wouldn't want to be responsible for any breakage.

The old rule applies:  If you [user - not packager] break it you get to
keep all the pieces!


> Even when we would do extensive testing, it is hard (read: impossible) to 
> test every combination of features of every given program or combinations 
> of programs. Things change and every change is a liability. That's the 
> difference between eg. a RHEL4 rsync (which is never updated, only fixed) 
> and an RPMforge rsync (always the latest).
> If you require stability and newer features in RPMforge packages a 
> combination of pinning RPMforge packages and a default policy of not 
> overriding official packages is extremely recommended.
> (See Johnny's mail for the details on how to achieve this)
> And if this isn't a FAQ yet, we should make one to point to it :)

Sounds like a great start for a new CentOS FAQ entry on using add-on


More information about the CentOS mailing list