-----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.
The idea is to have a clear workflow for SIG:
1/ Let's say a SIG have been approved. 2/ sig-admins are defined (members of the board) 3/ sig-admins request for a buildsystem target and workflow ( [build - -> testing -> release] at this point but can evolve according to needs). At this time we ask a ticket with the following information : - Short name (virt, cloud, storage, let's try to keep it simple) - What distribution they want to build against (5,6,7) - What external repositories they depend on (epel, rdo, whatever yum repo)
Not only relevant to EPEL, but in my opinion it should be a SIG decision (Core SIG may keep an eye on repo reputation and approve them in koji. i.e security concern) on what external repositories (and associated risks) they are ready to support.
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.
- -- Thomas.