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