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@xxxxxxxxxxxx> 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 > > Or > > - 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). > > Phil 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 packages. 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 :) Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.centos.org/pipermail/centos/attachments/20060310/2788b780/attachment.bin