On 26/02/16 09:44, Stephen John Smoogen wrote:
A staged/forked environment. This version is a lot more complicated
and deals with extra release management. Currently, Red Hat does
regular point releases (.1, .2, .3) of their main OS. In these point
releases, various items get major updates or backports to bring new
functionality to the base operating system. In this version, EPEL ties
into this staged environment by using a similar method as Fedora does.
Using a directory tree structure like:
EPEL/archives/{5.x, 6.x, 7.x}
EPEL/archives/updates/{5.x, 6.x, 7.x}
EPEL/current/5 -> 5.11/
EPEL/current/5.11/{x86_64,ppc64,x86_32}/
EPEL/current/6 -> 6.7/
EPEL/current/7 -> 7.2/
EPEL/updates/5 -> 5.11/
EPEL/updates/6 -> 6.7/
EPEL/updates/7 -> 7.2/
EPEL/updates/testing/{blah, blah}
EPEL/rawhide/{5, 6, 7}
This could also solve the issue of different distros releasing at
different times. You could have a symbolic link for each distro that
points to the current release for that particular distro so that CentOS
(and other) users won't get prematurely updated when a new point release
drops from RHEL but RHEL users won't have to wait, for example when RHEL
7.3 drops but before CentOS 7.3 you might have:
EPEL/centos/7 -> 7.2
EPEL/rhel/7 -> 7.3
Then a custom epel-release package for each distro is all you need to
make sure that the .repo file points to the correct symlink for that distro.
Peter