On Sat, Mar 28, 2015 at 4:32 PM, Carl George <carl.george at rackspace.com> wrote: > Howdy, > > My name is Carl, and I'm a developer for the IUS Community repository. > > CentOS users have easy access to the EPEL repo because the epel-release RPM is in the CentOS Extras repository. Obviously CentOS and EPEL have a special relationship, since they are both sponsored by Red Hat. A coworker suggested to me that it would be nice if the ius-release RPM could be included in Extras as well. I brought the idea up in IRC, and Karanbir suggested I draft up a specification that any third party repository can follow to be considered for inclusion. Here is what I have so far. > > https://gist.github.com/cgtx/b854281462a18007f509 > > If this looks familiar, it's because I used the IUS SafeRepo Initiative as a starting point. Please share your feedback and ideas. > > Carl George > Rackspace RPM Development Scientific Linux does this effectively. Unfortunately, if your reason to exist is "to be a byte for byte matching duplicate of RHEL", it gets awkward. And many of the 3rd party repositories can, and do conflict with the base RHEL packages and the base EPEL packages. And the difficulty of keeping things consistent does not go up in a linear fashion, it's more exponential or combinatorial. One classic such difficulty is the RPMforge/EPEL disagrrements about how to package and version nagios-plugins: the "nagios-plugins" from EPEL has only a few plugins, and the other plugins are in distinct packages. RPMforge chose to have most of the plugins in the basic "nagios-plugins" package itself, since they're all deployed form the same source package. So when the EPEL had a more recent verison of 'nagios-plugins', it would replace the RPMforge version and yank out all the subpackages, unless you added them back explicitly. And if RPMforge became more recent, it would try to update and break on all the packages form EPEL. "mysql-libs" is even worse, since no two 3rd party repos for MySQL can agree on a naming scheme for MySQL packages, and many of them mark "Obsoletes: mysql-libs" so that they can install gracefully against only the RHEL based stack. Perl module dependency resolution is also a !@#$, because of the dependencies on older and newer builds among alternative compnent trees. I ran into this headlong woth RT and Bugzilla some time back.