Hi! Sorry for the late reply. On 20.06.2008 00:49, Nikolay Ulyanitsky wrote: RPM Fusion is not started yet (but will hopefully soon). A add-on repo for Fedora is the first and main target; the RPM Fusion add-on repo for RHEL+EPEL is just a idea that some of the RPM Fusion developers (mainly I afaik) want to realize once RPM Fusion for Fedora is running properly. No, normally not. There might be only a few rare cases where conflicts might show up and are unavoidable (I can't think of any, but one never knows); that's the same in Fedora, where IIRC a handful of packages conflict explicitly ("Conflics: foo" in the spec file) or implicitly (conflicts on the file level) with other Fedora packages. No, not in the main repos RPM Fusion will provide. *Maybe* we in the long run RPM Fusion might start some additional repos with dedicated things -- like a "KDE4 for RHEL5" or "Kernel 2.6.26 for RHEL5" repo. Those will be in a special place for a subset of our users that are willing to accept replacements to get specific things realized -- but thats just a option we like to keep open for the long term and nothing that is planed for now. Packages that are possible to be shipped in Fedora/EPEL will normally not get accepted in RPM Fusion. In those rare cases where a existing package due to upstream or other changes suddenly is permitted to get shipped in Fedora/EPEL RPM Fusion will stop updating it as long as the update path for users is taken care of by Fedora/EPEL. That's a hard question and there are many ways to answer it; and he answers to this sort of questions quickly leads to misunderstandings and flamewars. So let me say just this: the main repos from RPM Fusion will be add-on repos for Fedora or RHEL/CentOS+EPEL. The goal is not to disturb those base sets we build and rely on. That's what a lot of people would define as compatibility (as EPEL is a 3rd party repo as well). As soon as more 3rd party repos get into the mix a lot of problems often show up for users as the ecosystem (rpm/yum) is not designed to properly handle this. A lot (but not all!) of those problems can be fixed without downsides for existing users; if that's the case then we/the package maintainer in question IMHO should fix the problem. Cu knurd