On Fri, Jul 12, 2019 at 06:58:53PM +0200, Fabian Arrotin wrote:
On 12/07/2019 18:35, Johnny Hughes wrote:
On 7/12/19 12:23 AM, Sandro Bonazzola wrote:
Il giorno mer 10 lug 2019 alle ore 22:53 Thomas Oulevey <thomas.oulevey@cern.ch mailto:thomas.oulevey@cern.ch> ha scritto:
Hello folks, In the planning of next Community build services, a new question came up. In the past we never allowed EPEL repositories to be used as external repositories for SIGs. Doing so, would allow to build against EPEL packages and not duplicate the work for maintainers in EPEL/SIGs. However it would mean also building against a moving target which can be difficult if EPEL policies are the same as today. As EPEL 8 is also in the making it would be good to hear what SIGs think about this specific issue. Let us know !Within Virt SIG, under oVirt project we are rebuilding a few packages from EPEL without modifications. Being able to tag into our repos packages which are available in EPEL would reduce the load on the SIG.
The issue is .. they change the versions out and you then lose that package. next build it fails with the new one .. what do you do? The old package is no longer available anywhere.
If you build that package .. then you can move to the new one whenever you want.
So there are pluses and minuses abound in both scenarios.
Just wondering : if people would like to consume epel pkgs, but still want to cherry-pick which version of pkgs they need/want : what about :
- creating tag/targets for epel (but not building *any* pkg there)
- rsync (without any delete) epel
- use "koji import" to import all epel pkgs, and also new versions when
new pkgs appear
That would mean : nothing to build on cbs, and people can just "cbs tag-build" existing imported pkgs.
Would that work for everybody ?
The problem is that there may be build/link issues when a new version of a package gets introduced in EPEL. Already build binaries may not be able to function with the updated package from EPEL, it may be required to rebuild some packages in the SIG.
For Gluster we have at least one of such a candidate (userspace-rcu). In order to prevent these issues, the old userspace-rcu needs to be provided by some repository too. Not sure if we should tag a build of an EPEL package into a repository provided by the SIG...
There are very few dependencies that Gluster has with EPEL. I am fine with rebuilding those few packages in order to keep things simple and prevent unexpected issues.
Niels