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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20151104/f7d788f2/attachment-0008.sig>