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
