[CentOS-devel] koji/mock/createrepo_c/pigz packages distributed in CentOS 7 - extras ?

[Brian Stinson]

On Nov 04 04:51, Johnny Hughes wrote:
> On 11/04/2015 12:59 AM, Jarek Polok wrote:
> > Hello all,
> > 
> > It seems that starting yesterday new packages:
> > 
> > koji/mock/createrepo_c/pigz/python-lockfile/python-munch
> > 
> > are distributed in CentOS7 Extras repo:
> > 
> > http://mirror.centos.org/centos/7/extras/x86_64/Packages/
> > 
> > 
> > I believe all of the above are already provided by EPEL7,
> > so why duplicate these ?
> > 
> > I guess that these may be specific versions needed for
> > cbs.centos.org buildsystem and I can see that these
> > are dependencies of centos-packager which also has
> > been added to extras:
> > 
> > but then wouldn;t it be better to distribute these
> > via an additional repository - like for SIG provided
> > packages, and not in a repository that is (probably)
> > enabled for most of CentOS users ?
> > 
> > It seems to me that this set of packages is targeted
> > at developer community, not at general users
> > community ?
> > 
> 
> EPEL is not a CentOS repository .. so we can't build directly against
> EPEL with our build systems.  We therefore are currently rebuilding
> things from EPEL if we need them for SIGs build dependencies or as
> requirements to run packages.
> 
> There has been discussion about building directly against EPEL, but
> since it is not a CentOS controlled repo, if/when they bump to a new
> version of a package (PackageA, lets say), it could cause issues with
> things SIGs that build against or require PackageA.
> 
> If we duplicate PackageA at build time (in extras or a SIG), and if
> someone has both extras (or a SIG) enabled and EPEL enabled then there
> is no conflict.  If EPEL then upgrades the PackageA and it is compatible
> with the packages in extras (or the SIG) that use PackageA, that is also
> fine .. the upgrade happens and everything works.
> 
> If, on the other hand, the new PackageA breaks something, then the SIG
> (or extras) can instruct people to add an exclude in their EPEL repo
> config so that the SIG or extras packages that need the older PackageA
> can work out the issues without everything being broken.
> 
> So, there are pluses or minuses to either approach .. and there are
> ongoing discussions as to what the best solution is.  The current
> practice though, is that CentOS can only rely on CentOS repos for build
> and run requirements.
> 

I will add that for this package set, we will be closely following the
corresponding EPEL builds. In this case, we're slightly ahead with the
koji client package because there were a few bugfixes that were rolled
in upstream. 

--Brian