'policy' for multiple versions of same software in EPEL

So... I've paid attention to the conversations around this because i was a long time zabbix user, so it affected me in that I had to build my own 'latest' packages usually or download from the maintainer's personal repository. If I remember correctly it has also been discussed around lots of web apps like bugzilla as well. But now its something that is potentially going to affect me more as I jumped on as a co-maintainer of collectd in the recent pre-orphaning package spree and started trying to get rspec-puppet packaged [1] due to requirements @dayjob. So in the sidebar discussion about collectd the following was in the thread: But a few weeks ago in the Zabbix discussion on list [2] I saw: I've read through the Packaging:Conflicts wiki. I just don't feel like it adequately addresses the EPEL 'newer' version scenario. Maybe that is just cause I'm missing something (in which case can someone clarify for me, and maybe we can make it clearer in the wiki?) or because it just isn't defined. I'll concede that some examples listed of packages that perform each of the various 'solutions' described would be awesome and might resolve some of the lack of clarity. So the two scenarios I'm looking at: 1: collectd [3] - to make version 5 available in epel5/6 will have to submit collectd5 package. Most of the work is done, but right now the created package 'conflicts' due to duplicate library files and the perl-Collectd module needing to be renamed. I can usually package up software pretty readily, and I don't know how to do what is needed to do this without more guidance (more admin than dev). Because of what the software is, I'd imagine most people are running either version 4 or version 5. Some people might be running both environments from the server side (separate collectors), but aren't likely to have a monitored (client) system active in both. 2: rubygem-rspec (no associated bugzilla entry that I am aware of yet) - to make rspec-puppet available in epel 5/6 version 2 of rspec needs to be made available. I assume this means that the same general concept of rspec2 package needing to be initiated begins. With this one there appears to be way more impact as there are at least 3 packages that build on top of rspec currently. [4] Because this is more of a library set of packages, and most of those packages perform different functionality for rspec that may not always be for the same end use cases it makes conflicts a harder possibility. So i'd imagine either a) have to do a parallel installable rspec2 release of all of them that conflicts so that the 'gems' themselves don't need to be adjusted or b) adjust the entire rubygem so that it behaves as rspec2 and make the other gems use rspec2 rather than rspec. thoughts? thanks greg/xaeth [1] https://bugzilla.redhat.com/show_bug.cgi?id=787350 [2] http://www.redhat.com/archives/epel-devel-list/2012-September/msg00037.html [3] https://bugzilla.redhat.com/show_bug.cgi?id=743894 [4] although upon further review.. it appears that none are branched into epel and all are current with rspec2, which negates a lot of the conflicts and actually would open them up to epel....