On Tue, Jul 08, 2008 at 03:14:18PM -0500, Lanny Marcus wrote: > > > >> Using client side filtering is not recommended, it creates more bugs, > > > >> than it can solve. The proper thing is to take care of it on the > > > >> server side, where the package owners are supposed to know how to > > > >> structure the repos. > Axel: Wasn't there a very long thread in this list, several months ago, > about EPEL and the problems that would cause, since they do not want to > include data that the other repositories include with their package > information? There would be a lot of conflicts. I think the issue was not data, but lack of cooperation in the sense of checking against the other 3rd party repos on package conflicts. > My belief is that priorities works well on CentOS (I see about 300 packages > excluded, when I use yum to update on my desktops) That's probably already the problem. What 300 (!) package conlfict between which repos? I know that I'm trying to keep ATrpms 100% conflict free with CentOS5 for example (pm-utils was a bug that was now fixed) > and that not to use priorities is asking for trouble, if one has 3rd > party repositories enabled. The goal is to keep the boxes up to > date and not to get them clobbered, by something from a repository > with a lower priority. That is very sound, IMHO. No need to CC > me. Lanny See the example for the different packaging of clamav where you might get a different set of clamav subpackages gathered from different repos due to priorities setups. You don't actually protect the system but you add to its destabilizaton, it's a false sense of security. Bottom line is: The issue with package conflicts need to be fixed by humans, not filters - the first step is to allow users the choice of a pure add-on repo and a mixed one (like ATrpms does with abusing "stable" and "testing" repos). The next step is cooperating with other repos to avoid any clashes up to the point that these repos may get merged. That's what rpmrepo.org is about. -- Axel.Thimm at ATrpms.net