Actually, that was what I meant when I said that the packages would clash with one another, but I just couldn't find the right words. :-) One more problem which I've not experienced myself is the problem of "perpetual updates". Same packages from different repositories would vie for installation, so the user would find himself/herself updating the same packages over and over again. Michael Schwendt wrote: >>It's not wise to >>mix repositories indiscriminately as packages can clash with one >>another, thereby causing conflicts. >> >> > >Less of a problem. Conflicts cause package resolvers [like yum, up2date, >or apt-get] to terminate with a fatal error message and refuse to install >packages. > >More of a problem are packages with the same name, but different version >or different release or files in different locations. They cause an >upgrade race between multiple repositories. > >Another problem are repositories which rename and replace packages from >Core, introducing a new package namespace and a different ABI, breaking >src.rpms (which obviously do "BuildRequires: somename-devel" and not >"BuildRequires: somename2-devel") and moving away from the [hopefully] >widely tested Core packages. > >Very annoying problems are packages with the same name and version, which >are out-of-sync with regard to the applied patches/fixes. Example: >A package in repository 'A' may include a patch for a segmentation >fault. A package with the same name and version in repository 'B', but >with a higher release, is seen as an upgrade, although it does not include >the patch. The segfault is back. Other forms of run-time misbehaviour >are possible and have been observed in the wild. > > >
