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 front?] > > 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 repos. Phil