-----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-----