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? -- Florin Andrei http://florin.myip.org/
On Dec 4, 2007 1:12 PM, Florin Andrei <florin at 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?RPMForge and EPEL have several conflicting packages, so yes you may run into trouble. EPEL has stated that playing nicely with other repos is not a goal of theirs. I would consider them a 'single source' repo. If you're using them, don't use any other 3rd party repos. -- During times of universal deceit, telling the truth becomes a revolutionary act. George Orwell
On Dec 4, 2007 11:12 AM, Florin Andrei <florin at 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.. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice"
Florin Andrei 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? >The real, no bullcrap, and bottom line answer to this question is: NO!!!!!!!!!!!!!!! ATRPMS, RPMForge, and EPEL contain many conficts if all are used together. You can mitigate this by using the priorities plugin in yum ... but eventually you will also have to use "exclude=" and maybe even "includepkgs=" options. See "man yum.conf" for details. No amount of posting or ranting / complaining on the CentOS mailing list will solve this problem. ATRPMS, RPMForge, and EPEL each have mailing lists and each have packaging guidelines and community leaders, etc. Those mailing lists are the place where these issues MIGHT be solved ... not here. The CentOS Project has no input into what ANY of these repos do, so complaining, whining, bitching, moaning, ranting, screaming, gnashing of teeth, or any other thing ... when done on this list ... will have no impact on the situation. SO, please take it to the appropriate place. As to what my personal option is about this situation .. please see this thread (on the appropriate mailing list): http://www.redhat.com/archives/epel-devel-list/2007-April/msg00129.html Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20071207/4acbbf42/attachment-0003.sig>
Florin Andrei 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? >This thread is now moderated off. -- Karanbir Singh : http://www.karan.org/ : 2522219 at icq