[CentOS-devel] including 3rd party repo release RPMs in Extras

[Nico Kadel-Garcia]

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.