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
_______________________________________________
epel-devel mailing list
[email protected]
http://lists.fedoraproject.org/admin/lists/[email protected]
