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.