[CentOS-devel] planning and coordination with EPEL

On Wed, Sep 24, 2014 at 3:31 AM, Thomas Oulevey <thomas.oulevey at cern.ch> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> On 09/24/2014 01:13 AM, Jim Perrin wrote:
>
>>> Do you mean, we will directly consume EPEL (if required) in SIGs?
>>> As of now we add required packages from EPEL to the build root
>>> manually.
>>
>>
>> This would be something for the people running the build system to
>> answer. Currently epel-release is available, but it's a two step
>> process. First yum install epel-release, *then* install whatever
>> deps you need. I'm not certain if this can be managed for a
>> particular build target within koji, so I'll defer to someone else
>> to answer.
>>
>
> EPEL can be configured as an external repository
> (https://fedoraproject.org/wiki/Koji/ExternalRepoServerBootstrap) and
> so packages are directly available in the buildroot.

EPEL is built into the published "mock" RPMS as a default repository.
Why not, since the  mock RPM itself is published from EPEL? It's
actually extra work to *disable* EPEL, to avoid accidental
dependencies

Unfortunately, this casual inclusion is somewhat unstable. Because
EPEL does not keep old versions of its packages around, and because
some components can migrate from EPEL publication to RHEL inclusion,
you can wind up with components built against an older version in EPEL
that is no longer available, and are now found in RHEL or CentOS.
Worse, you can wind up with working older versions of EPEL components
that no longer have their dependencies in an easily accessible public
repository and are difficult to include for new deployments. That way
lies madness.

> At work, we build against EPEL in Koji for the last 2 years and we
> never experience any issue. They only important parameter to remember
> is the package retention policy (only last version is kept in EPEL
> stable repo, no yum downgrade, etc...) so you need to keep a eye on
> their process.

This.

I personally deal with it by keeping a nightly rsync of EPEL around,
without using "--delete" and following up with relevant 'createrepo'
commands, so old packages remain available on my internal EPEL mirror.
But it's not completely reliable.