[CentOS-devel] [EPEL-devel] [Proposal] Converge EPEL and CBS

[Fabian Arrotin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22/09/15 19:15, Kevin Fenzi wrote:
> Well, personally, I'd like to hear why less difficult methods wont
> work:
> 
> 1. Just enable EPEL repo in CBS? I assume this won't work because 
> people sometimes want to rebuild things? but can't they just make
> sure they are newer than the EPEL version? or what are the use
> cases here?
> 
> 2. Setup a sync script to just import all EPEL builds into CBS.
> Then they are full builds just like they were done there, and can
> be untagged/tagged/etc.
> 
> I guess I don't have enough data about the use cases that are
> pressing here.
> 
> kevin

True, and that was one of the possible solutions I wanted to come with
too.
As said before, I'd like to avoid #1 for multiple reasons (including
not having SIGs consumers to have a hard dep on the whole Epel
repository, and when SIGs will build and provide higher versions,
sometimes rebuilt from rawhide or another Fedora release)

#2 would have my vote, as then, as you said, SIGs
maintainers/developers only have to "tag-build" specific packages
they'd like to see landing in their specific SIG repo, and have repo
closure without any need for $SIG-release.rpm needing epel-release
automatically. The idea is that one one user install a -release.rpm
package, he can use/find everything needed through that repository.
(when configuring for example gluster/xen/etc ..)
That would mean rebuilding the whole EPEL repository first, and then
"just" keeping it in sync with "upstream" epel.

- -- 
Fabian Arrotin
The CentOS Project | http://www.centos.org
gpg key: 56BEC54E | twitter: @arrfab
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlYBqWsACgkQnVkHo1a+xU5UtACfRIJ/Tan7UjDwKEFmE0XSmYKe
ZOcAniqI/c57JvreywjgFRdm0tjNYQ4A
=4Oyv
-----END PGP SIGNATURE-----