On Sun, 2005-07-17 at 20:28 -0400, Tony Nelson wrote: > At 2:31 PM +0200 7/17/05, Levin Fritz wrote: > >Hello Mirco, > >in general, mixing too many repositories is not a good idea, because the > >more repositories you use, the more likely there's some sort of conflict > >between them. In particular, > > > >* don't mix Livna and Freshrpms/Dag. They provide a lot of the same > >packages but the maintainers don't work together so there's a high > >chance of conflicts. You should either enable Livna and disable > >Freshrpms and Dag or disable Livna and enable Freshrpms and Dag. > > Since I don't really understand it myself and would like to know: is it > safe to do yum installs from mutually incompatible repos by enabling only > one of them at a time? Yes and no. Supposing there are two mutually incompatible repo sets, A and B. Both contain software that you want to use that isn't included in the other set. I would be inclined to enable normally the set (let's say A) that had the highest number of packages in it that I wanted. I could then install the remaining packages from B using: # yum --enablerepo=B install pkg1 pkg2 ... This will work in many situations. However, it may be that some of the packages you want from B have dependencies on libraries or other packages that you are already sourcing from A. So some of your packages from A *may* be replaced by the versions from B. This *may* result in dependency errors next time you do a "yum update" without enabling B. As a result, you might consider disabling both A and B by default. But then you would miss out on updates (potentially important security updates) from both A and B. So the answer really is that it depends on your particular set of circumstances and requirements. But if you can source all your requirements without using mutually-incompatible repos, it'll make life simpler. > How well does using smartpm do to avoid such troubles? (Modulo such > packages being added later to a high priority repo such as extras and the > confusion that will result.) Good question. I don't know. Paul. -- Paul Howarth <paul@xxxxxxxxxxxx>
