On Dec 4, 2007 11:12 AM, Florin Andrei florin@andrei.myip.org wrote:
Following Fabian's blog post re: RPMForge being rebuilt for EL5, I've a question:
Are there any compatibility problems between RPMForge and EPEL? In other words, if I enabled EPEL previously, will I be able to enable RPMForge as well without running into trouble?
Speaking from a technical standpoint, the biggest issue with mixing any different repos is that they use different packaging guidelines. The hyperbole case: package repo A uses SuSE standards, repo B were to use Fedora 1.x standards, repo C were to use current Fedora standards, and repo D were to use Mandrake standards.. you would end up with either file conflicts or worse yet lack of conflicts but hidden requirements (script from A expects files to be in /opt/blah/bin for some reason but you got that package from E because it was newer and it places things in /srv/snozzberry/bin instead.
The more common case I have found has been odd dependency chains from one side or another because of unclear guidelines. In most production environments, I tend to choose one repository and then work with that one only to get the job done. For some things it was ATrpms, others DAG, and other EPEL. If the item I needed was in one but not the other.. getting it into the one repository I was working with was easier than trying to figure out how to find any unknown unknowns in hidden conflicts.
As DAG has said several times in mailling lists.. the proper thing to do is not use a repository directly anyway. You should have an internal mirror of the main repo, and then several sub-repo's of just the packages you want your systems to have. You should have a testing routine where you take new packages test that they work with your environment and then push them out from the sub-repos. He has written several tools to make this possible..