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 ?
Best Regards
Jarek
__ ------------------------------------------------------- _ Jaroslaw_Polok __________________ CERN - IT/OIS/WLS _ _ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _ ______________________________________+41_75_411_9487 _
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.
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
-
Brian Stinson -
Jarek Polok -
Johnny Hughes