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

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-0004.sig>