[CentOS] Karanbir CentOS REPO - Breakability?
mailing-lists at hughesjr.com
Fri Mar 10 11:26:56 UTC 2006
On Thu, 2006-03-09 at 13:32 -0500, Phil Schaffner wrote:
> On Wed, 2006-03-08 at 18:43 -0700, Craig White wrote:
> > On Wed, 2006-03-08 at 17:23 -0800, Jim Smith wrote:
> > > --- Johnny Hughes <mailing-lists at hughesjr.com> wrote:
> > > >
> > > > ermmm ... it is a REBUILD of fedora extras ... what do you expect?
> > > > Gentoo packges?
> > > >
> > >
> > > No I did not expect Gentoo packages, I expected Debian sid packages.
> > >
> > > On a serious note if i wanted broken packages, all i had to do was to
> > > :-
> > >
> > > - install fedora rawhide
> > > - enable ATRPMS
> - install CentOS4
> - enable atrpms and rpmforge and/or kbs
> > > What's the purpose of blindly following ALL fedora rebuilds? What
> > > will happen when the FC5 rebuilds are churned out? Even more broken-ness?
> > -----
> > For the record, I think ATRPMS is a tremendous resource and your attempt
> > a humor didn't need to take a back handed slap at someone who gives a
> > tremendous amount of time and energy to providing a repository for
> > bleeding edge sounds and graphics applications. Without ATRPMS, it would
> > be incredibly difficult to built a mythtv system on Fedora or CentOS.
> ATrpms is useful for things like MythTV; however Axel Thimm's packages
> do not mix well with other repos like Karanbir's or RPMforge. Have been
> fighting breakages of yum, yumex, smartpm, and associated config files
> on a couple of systems on which I have had mythtv or other multimedia
> stuff working, and made the mistake of enabling atrpms and running "yum
> update". Had to manually downgrade some packages to get things working
> at all and yum is still complaining that it can't find sqlite.
> Things may well work if you use ATrpms repo alone on top of a "vanilla"
> system, and I have managed to get things to work by picking selected
> packages and dependencies for mythtv, transcode, etc. from ATrpms with
> smart (against Axel's recommendation to use all or none of his
> packages), but from repeated painful experiences, would recommend
> against wholesale mixing with Dag's, Dries', or Karanbir's repos (which
> generally do mix well together).
Good info Phil, thanks
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.
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.
There are things available to prevent this breakage ...
1. Use the yum config variable for repos named "includepkgs=". This
variable will only use certain packages from a repo ... so if you have
5 packages installed from Dag's repo, when you run an update it will
only look at those five packages. This goes in the repo section (where
baseurl= or mirrorlist= is).
2. Use the yum config variable for repos names "exclude=". This will
prevent looking for updates for the packages listed. This can be a repo
option ... or in the main yum.conf file. When used in repos, it
excludes that package from that repo .. when used in the main yum.conf
file it excludes updating that package at all.
3. Use the plugin from the extras repo named yum-plugin-protectbase.
This plugin allows you to protect certain repos (like [os] and
[updates]) so that no updates can happen to packages from these repos
except from other protected repos.
All of these things will prevent getting unwanted updates to core
Again ... I am not saying that any of the repos are bad, people just
need to take responsibility for their yum setups.
A repo has to be self sufficient (meaning it has to be able to meet all
it's own dependencies) ... that will cause some package overlap between
repos ... AND overlap between repos can cause unwanted affects.
Thanks to all the 3rd party repo maintainers ... they all do a great
service. We just need to use these resources a little more wisely.
Last time I ran yum ... it told me every single package it was going to
update and I had the opportunity to say yes or no :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.centos.org/pipermail/centos/attachments/20060310/2788b780/attachment.bin
More information about the CentOS