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 !
On Wed, 10 Jul 2019 at 16:52, Thomas Oulevey thomas.oulevey@cern.ch wrote:
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.
1. What are the policies that EPEL would need to change? 2. What are the parts of EPEL that are a moving target compared to the continuous release method of CentOS?
As EPEL 8 is also in the making it would be good to hear what SIGs think about this specific issue.
Let us know !
-- Thomas Oulevey _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Hi Stephen,
Thanks for your questions.
Inline my feedback.
On 10.07.19 22:57, Stephen John Smoogen wrote:
- What are the policies that EPEL would need to change?
EPEL is shipping only latest build in their repo. We can't build against older packages. Another issue is that koji doesn't allow that either. The intermediate repo metadata only contains latest builds and it is not configurable as far as I remember.
- What are the parts of EPEL that are a moving target compared to the
continuous release method of CentOS?
We can build packages and stick to them for a whole lifecycle of a SIG project release for both "Requires:" and "Buildrequires:".
I am sure there are other concerns that can be discussed by the pkgs maintainers.
On Wed, 10 Jul 2019 at 17:09, Thomas Oulevey thomas.oulevey@cern.ch wrote:
Hi Stephen,
Thanks for your questions.
Inline my feedback.
On 10.07.19 22:57, Stephen John Smoogen wrote:
- What are the policies that EPEL would need to change?
EPEL is shipping only latest build in their repo. We can't build against older packages. Another issue is that koji doesn't allow that either.
Understood, we are hoping to keep some around but do you guys compile against older copies of CentOS? I thought it was compiled only with the latest bits. Second koji does work with external packages this way because that is how we compile RHEL. For RHEL-7, we only see the latest RHEL download we got from CDN that day.
The intermediate repo metadata only contains latest builds and it is not configurable as far as I remember.
I am not sure what that means.
- What are the parts of EPEL that are a moving target compared to the
continuous release method of CentOS?
We can build packages and stick to them for a whole lifecycle of a SIG project release for both "Requires:" and "Buildrequires:".
So the CBS points not at latest CentOS but has copies of every package that CentOS ever built ? [AKA you import in whatever glibc rpm was used and it is stored in the lookaside and koji places? Cool.
I am sure there are other concerns that can be discussed by the pkgs maintainers.
I don't doubt. We can work through them.
-- Thomas Oulevey
On 7/10/19 4:09 PM, Thomas Oulevey wrote:
Hi Stephen,
Thanks for your questions.
Inline my feedback.
On 10.07.19 22:57, Stephen John Smoogen wrote:
- What are the policies that EPEL would need to change?
EPEL is shipping only latest build in their repo. We can't build against older packages. Another issue is that koji doesn't allow that either. The intermediate repo metadata only contains latest builds and it is not configurable as far as I remember.
- What are the parts of EPEL that are a moving target compared to
the continuous release method of CentOS?
We can build packages and stick to them for a whole lifecycle of a SIG project release for both "Requires:" and "Buildrequires:".
I am sure there are other concerns that can be discussed by the pkgs maintainers.
Would it be possible to permit some SIGs to opt into EPEL if they desire?
Or to put another way:
The EPEL project has a Special Interest in EL packages. While this isn't a CentOS SIG, it is a Group. Existing CentOS SIGs are able to opt into depending on CentOS SIGs. Would permitting SIGs to opt into depending on EPEL be much different?
Pat
On Thu, 11 Jul 2019 at 09:25, Pat Riehecky riehecky@fnal.gov wrote:
On 7/10/19 4:09 PM, Thomas Oulevey wrote:
Hi Stephen,
Thanks for your questions.
Inline my feedback.
On 10.07.19 22:57, Stephen John Smoogen wrote:
- What are the policies that EPEL would need to change?
EPEL is shipping only latest build in their repo. We can't build against older packages. Another issue is that koji doesn't allow that either. The intermediate repo metadata only contains latest builds and it is not configurable as far as I remember.
- What are the parts of EPEL that are a moving target compared to
the continuous release method of CentOS?
We can build packages and stick to them for a whole lifecycle of a SIG project release for both "Requires:" and "Buildrequires:".
I am sure there are other concerns that can be discussed by the pkgs maintainers.
Would it be possible to permit some SIGs to opt into EPEL if they desire?
Or to put another way:
The EPEL project has a Special Interest in EL packages. While this isn't a CentOS SIG, it is a Group. Existing CentOS SIGs are able to opt into depending on CentOS SIGs. Would permitting SIGs to opt into depending on EPEL be much different?
It might require us to be a CentOS SIG also (which I don't currently see a problem with) and also have a way to make those packages available to the koji in way which doesn't break builders. [AKA some sort of local mirror which allows for keeping old copies of rpms.]
Pat
-- Pat Riehecky
Fermi National Accelerator Laboratory www.fnal.gov www.scientificlinux.org
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Thu, Jul 11, 2019, at 08:38, Stephen John Smoogen wrote:
On Thu, 11 Jul 2019 at 09:25, Pat Riehecky riehecky@fnal.gov wrote:
On 7/10/19 4:09 PM, Thomas Oulevey wrote:
Hi Stephen,
Thanks for your questions.
Inline my feedback.
On 10.07.19 22:57, Stephen John Smoogen wrote:
- What are the policies that EPEL would need to change?
EPEL is shipping only latest build in their repo. We can't build against older packages. Another issue is that koji doesn't allow that either. The intermediate repo metadata only contains latest builds and it is not configurable as far as I remember.
- What are the parts of EPEL that are a moving target compared to
the continuous release method of CentOS?
We can build packages and stick to them for a whole lifecycle of a SIG project release for both "Requires:" and "Buildrequires:".
I am sure there are other concerns that can be discussed by the pkgs maintainers.
Would it be possible to permit some SIGs to opt into EPEL if they desire?
Or to put another way:
The EPEL project has a Special Interest in EL packages. While this isn't a CentOS SIG, it is a Group. Existing CentOS SIGs are able to opt into depending on CentOS SIGs. Would permitting SIGs to opt into depending on EPEL be much different?
It might require us to be a CentOS SIG also (which I don't currently see a problem with) and also have a way to make those packages available to the koji in way which doesn't break builders. [AKA some sort of local mirror which allows for keeping old copies of rpms.]
Pat
-- Pat Riehecky
Fermi National Accelerator Laboratory www.fnal.gov www.scientificlinux.org
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-- Stephen J Smoogen. _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
To me this isn't a "building" question, this is a "delivery" question. Currently the guidance is for the SIGs to own their dependency chain, and to ship their deliverables depending on things that are self-contained (or self-contained to CentOS-built content at least).
Currently there is a lot of EPEL rebuild activity going on to support the SIGs, and I think this is where we can make some improvements with the converged git structure. We, in general, want to make it easier to take things from Fedora/EPEL branches and convert them into CentOS branches, and that workflow would make the process of consuming EPEL packages (even with a rebuild) a lot less painful.
--Brian
On Thu, Jul 11, 2019 at 10:43 AM Brian Stinson brian@bstinson.com wrote:
To me this isn't a "building" question, this is a "delivery" question. Currently the guidance is for the SIGs to own their dependency chain, and to ship their deliverables depending on things that are self-contained (or self-contained to CentOS-built content at least).
Currently there is a lot of EPEL rebuild activity going on to support the SIGs, and I think this is where we can make some improvements with the converged git structure. We, in general, want to make it easier to take things from Fedora/EPEL branches and convert them into CentOS branches, and that workflow would make the process of consuming EPEL packages (even with a rebuild) a lot less painful.
As someone who builds and uses EPEL, I'd really rather have downstream consumers in CentOS contributing upstream in Fedora EPEL. I'm aware that a number of my packages wind up getting forked into CentOS SIGs because of the current policy, and while it is their right to do so, I've always been unhappy with that because their changes are more or less walled off and they don't care to upstream anything.
CentOS and EPEL should not be a one-way street, and it is. In my view, that's the underlying problem. If, for example, Koji EPEL build references were auto-populated into the CBS so that they can be tagged in, and if CentOS and Fedora accounts were federated so that CentOS folks can submit PRs to Fedora Dist-Git on EPEL branches and get those merged and built in Fedora Koji for EPEL to tag into CBS, that'd be way better.
Sadly, I don't know if that's even possible today...
On Thu, 11 Jul 2019 at 10:56, Neal Gompa ngompa13@gmail.com wrote:
On Thu, Jul 11, 2019 at 10:43 AM Brian Stinson brian@bstinson.com wrote:
To me this isn't a "building" question, this is a "delivery" question.
Currently the guidance is for the SIGs to own their dependency chain, and to ship their deliverables depending on things that are self-contained (or self-contained to CentOS-built content at least).
Currently there is a lot of EPEL rebuild activity going on to support
the SIGs, and I think this is where we can make some improvements with the converged git structure. We, in general, want to make it easier to take things from Fedora/EPEL branches and convert them into CentOS branches, and that workflow would make the process of consuming EPEL packages (even with a rebuild) a lot less painful.
As someone who builds and uses EPEL, I'd really rather have downstream consumers in CentOS contributing upstream in Fedora EPEL. I'm aware that a number of my packages wind up getting forked into CentOS SIGs because of the current policy, and while it is their right to do so, I've always been unhappy with that because their changes are more or less walled off and they don't care to upstream anything.
CentOS and EPEL should not be a one-way street, and it is. In my view, that's the underlying problem. If, for example, Koji EPEL build references were auto-populated into the CBS so that they can be tagged in, and if CentOS and Fedora accounts were federated so that CentOS folks can submit PRs to Fedora Dist-Git on EPEL branches and get those merged and built in Fedora Koji for EPEL to tag into CBS, that'd be way better.
Sadly, I don't know if that's even possible today...
Not without a lot of work. [I doubt any simple import would work as the two systems are so far apart in data structures.. but some sort of merging might be possible.] I believer we are working on how that would be possible but it will take a lot of focus which means other things wanted get droppeed or we drop focus on it for a while to make other things happen.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
One additional problem I can think of is arches, altarch specifically. Currently CBS can build armhfp, even if only Arrfab uses it. Using epel would mean importing also our unofficial rebuild for armhfp.
El 11/7/19 a las 13:01, Stephen John Smoogen escribió:
On Thu, 11 Jul 2019 at 10:56, Neal Gompa <ngompa13@gmail.com mailto:ngompa13@gmail.com> wrote:
On Thu, Jul 11, 2019 at 10:43 AM Brian Stinson <brian@bstinson.com <mailto:brian@bstinson.com>> wrote: > > > To me this isn't a "building" question, this is a "delivery" question. Currently the guidance is for the SIGs to own their dependency chain, and to ship their deliverables depending on things that are self-contained (or self-contained to CentOS-built content at least). > > Currently there is a lot of EPEL rebuild activity going on to support the SIGs, and I think this is where we can make some improvements with the converged git structure. We, in general, want to make it easier to take things from Fedora/EPEL branches and convert them into CentOS branches, and that workflow would make the process of consuming EPEL packages (even with a rebuild) a lot less painful. > As someone who builds and uses EPEL, I'd really rather have downstream consumers in CentOS contributing upstream in Fedora EPEL. I'm aware that a number of my packages wind up getting forked into CentOS SIGs because of the current policy, and while it is their right to do so, I've always been unhappy with that because their changes are more or less walled off and they don't care to upstream anything. CentOS and EPEL should not be a one-way street, and it is. In my view, that's the underlying problem. If, for example, Koji EPEL build references were auto-populated into the CBS so that they can be tagged in, and if CentOS and Fedora accounts were federated so that CentOS folks can submit PRs to Fedora Dist-Git on EPEL branches and get those merged and built in Fedora Koji for EPEL to tag into CBS, that'd be way better. Sadly, I don't know if that's even possible today...Not without a lot of work. [I doubt any simple import would work as the two systems are so far apart in data structures.. but some sort of merging might be possible.] I believer we are working on how that would be possible but it will take a lot of focus which means other things wanted get droppeed or we drop focus on it for a while to make other things happen.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org <mailto:CentOS-devel@centos.org> https://lists.centos.org/mailman/listinfo/centos-devel-- Stephen J Smoogen.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Wed, Jul 10, 2019 at 4:58 PM Stephen John Smoogen smooge@gmail.com wrote:
On Wed, 10 Jul 2019 at 16:52, Thomas Oulevey thomas.oulevey@cern.ch wrote:
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.
- What are the policies that EPEL would need to change?
- What are the parts of EPEL that are a moving target compared to the continuous release method of CentOS?
EPEL does not keep copies of older versions of software in the public mirrors, they discard them. This means that old dependencies for home users, or tested stable releases for production use, may evaporate without notice as new releases are published. I've been bitten by this a few times, and helped set up internal mirrors or "reposync" rathter than rsync based mirrors to keep the old packages available.
EPEL is also at risk of RHEL releasing a commercial version that overlaps, especially in a commercial channel, and having to decide whether to discard the EPEL release or continue it. This is precisely what happened with ansible. It's a built-in risk, which EPEL has tried to keep under control.
By the way, for others who might want to play with mock and EPEL component building early, I've published a reposync tool for RHEL 8 boxes to grab all the enabled channels at
https://github.com/nkadel/nkadel-rsync-scripts/blob/master/reposync-rhel-8.s... - reposync script to buld local mirror of RHEL 8 channels on subscribed host
https://github.com/nkadel/nkadel-rhel-8-mockrepo - mock and python macro RPM building tools, tested and working on RHEL 8.
I'll also point out that the epel-8-x86_64.cfg, or similar configs, need the "best" option to "best=0", to resolve some of the "module" dependencies.
As EPEL 8 is also in the making it would be good to hear what SIGs think about this specific issue.
Let us know !
I'm not a SIG, just someone who publishes a lot of EPEL requiring ports of software
Hi,
On Wed, Jul 10, 2019 at 10:53 PM Thomas Oulevey thomas.oulevey@cern.ch wrote:
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.
In CloudSIG we currently are explicit about not supporting enabling EPEL repos to deploy OpenStack. We are rebuilding the required deps in the SIG repo when needed. The main reasons for this is that we want to stay with specific versions of dependencies for stable releases and not following latest builds in EPEL on every supported release. Also, rebuilding them in CBS allows us to test any update before pushing it to the actual repos.
Let us know !
Best regards,
Alfredo
-- Thomas Oulevey _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Thu, 11 Jul 2019 at 05:16, Alfredo Moralejo Alonso amoralej@redhat.com wrote:
Hi,
On Wed, Jul 10, 2019 at 10:53 PM Thomas Oulevey thomas.oulevey@cern.ch wrote:
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.
In CloudSIG we currently are explicit about not supporting enabling EPEL repos to deploy OpenStack. We are rebuilding the required deps in the SIG repo when needed. The main reasons for this is that we want to stay with specific versions of dependencies for stable releases and not following latest builds in EPEL on every supported release. Also, rebuilding them in CBS allows us to test any update before pushing it to the actual repos.
Those are valid reasons for doing that. There is a side effect that people seem to want both and then our two groups are each blamed for breaking each other. But that is mostly people not reading the directions and aiming a loaded gun at their foot.
Do you use any other SIG work or is it a 'we rebuild everything we need and don't rely on others'? Also would it help you to rebuild or push back fixes if the source code you used for that was shared?
Let us know !
Best regards,
Alfredo
-- Thomas Oulevey _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Thu, Jul 11, 2019 at 1:39 PM Stephen John Smoogen smooge@gmail.com wrote:
On Thu, 11 Jul 2019 at 05:16, Alfredo Moralejo Alonso amoralej@redhat.com wrote:
Hi,
On Wed, Jul 10, 2019 at 10:53 PM Thomas Oulevey thomas.oulevey@cern.ch wrote:
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.
In CloudSIG we currently are explicit about not supporting enabling EPEL repos to deploy OpenStack. We are rebuilding the required deps in the SIG repo when needed. The main reasons for this is that we want to stay with specific versions of dependencies for stable releases and not following latest builds in EPEL on every supported release. Also, rebuilding them in CBS allows us to test any update before pushing it to the actual repos.
Those are valid reasons for doing that. There is a side effect that people seem to want both and then our two groups are each blamed for breaking each other. But that is mostly people not reading the directions and aiming a loaded gun at their foot.
Do you use any other SIG work or is it a 'we rebuild everything we need and don't rely on others'? Also would it help you to rebuild or push back fixes if the source code you used for that was shared?
We face different scenarios:
- For content provided by other SIGs as Ceph (StorageSIG), qemu/kvm (VirtSIG) or some monitoring (OpsTools), we consume them directly from the SIG repos for the version we want to use. - In some (few) cases, there are specific libraries or packages that we need and have been built in other SIGs or by CentOS infra. In those cases we tag them in CloudSIG tags and include in our repos. - For dependencies which are not in other SIGs, we rebuild them in CBS using Fedora specs (typically using epel, rawhide or recent branches). In some cases, if we need fixes that could be useful in Fedora/EPEL we try to push them. Note that in some cases we need specific changes to rebuild in CBS, i.e. removing python3 subpackages, etc...
Let us know !
Best regards,
Alfredo
-- Thomas Oulevey _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-- Stephen J Smoogen.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Thu, Jul 11, 2019 at 11:16:11AM +0200, Alfredo Moralejo Alonso wrote:
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.
In CloudSIG we currently are explicit about not supporting enabling EPEL repos to deploy OpenStack. We are rebuilding the required deps in the SIG repo when needed. The main reasons for this is that we want to stay with specific versions of dependencies for stable releases and not following latest builds in EPEL on every supported release.
I'd really like to see modularity used to address this problem. This is one of the things that it's _for_.
Also, rebuilding them in CBS allows us to test any update before pushing it to the actual repos.
Sorry, I'm not familiar with the process here. How does rebuilding help with testing? Doesn't it mean you have something _less_ tested?
On Wed, Jul 24, 2019 at 8:50 PM Matthew Miller mattdm@mattdm.org wrote:
On Thu, Jul 11, 2019 at 11:16:11AM +0200, Alfredo Moralejo Alonso wrote:
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.
In CloudSIG we currently are explicit about not supporting enabling EPEL repos to deploy OpenStack. We are rebuilding the required deps in the SIG repo when needed. The main reasons for this is that we want to stay with specific versions of dependencies for stable releases and not following latest builds in EPEL on every supported release.
I'd really like to see modularity used to address this problem. This is one of the things that it's _for_.
Also, rebuilding them in CBS allows us to test any update before pushing it to the actual repos.
Sorry, I'm not familiar with the process here. How does rebuilding help with testing? Doesn't it mean you have something _less_ tested?
What helps is not rebuilding packages (I'm fine with using EPEL packages if they are available) but publishing packages in SIG's managed repos instead of just enabling EPEL repos. I can test those builds (whether rebuilt or just cross-tagged) before tagging and pushing them to the actual repos.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Thu, Jul 25, 2019 at 02:17:39PM +0200, Alfredo Moralejo Alonso wrote:
Sorry, I'm not familiar with the process here. How does rebuilding help with testing? Doesn't it mean you have something _less_ tested?
What helps is not rebuilding packages (I'm fine with using EPEL packages if they are available) but publishing packages in SIG's managed repos instead of just enabling EPEL repos. I can test those builds (whether rebuilt or just cross-tagged) before tagging and pushing them to the actual repos.
Ah, that makes sense. I'm definitely in favor of figuring out how to do the cross-tagging here.
On 25/07/2019 15:05, Matthew Miller wrote:
On Thu, Jul 25, 2019 at 02:17:39PM +0200, Alfredo Moralejo Alonso wrote:
Sorry, I'm not familiar with the process here. How does rebuilding help with testing? Doesn't it mean you have something _less_ tested?
What helps is not rebuilding packages (I'm fine with using EPEL packages if they are available) but publishing packages in SIG's managed repos instead of just enabling EPEL repos. I can test those builds (whether rebuilt or just cross-tagged) before tagging and pushing them to the actual repos.
Ah, that makes sense. I'm definitely in favor of figuring out how to do the cross-tagging here.
That was basically what I proposed in that thread earlier : <paste> 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 ? </paste>
We just import all EPEL pkgs, keep all versions and people can tag the ones they need/want/have tested :-)
On Thu, Jul 25, 2019 at 3:15 PM Fabian Arrotin arrfab@centos.org wrote:
On 25/07/2019 15:05, Matthew Miller wrote:
On Thu, Jul 25, 2019 at 02:17:39PM +0200, Alfredo Moralejo Alonso wrote:
Sorry, I'm not familiar with the process here. How does rebuilding help with testing? Doesn't it mean you have something _less_ tested?
What helps is not rebuilding packages (I'm fine with using EPEL
packages if
they are available) but publishing packages in SIG's managed repos
instead
of just enabling EPEL repos. I can test those builds (whether rebuilt or just cross-tagged) before tagging and pushing them to the actual repos.
Ah, that makes sense. I'm definitely in favor of figuring out how to do
the
cross-tagging here.
That was basically what I proposed in that thread earlier :
<paste> 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 ?
</paste>
Yeap, that'd work for me. The only potential issue i see is conflicting NVRs between CBS rebuilt packages vs imported from epel. i.e. if some SIG has rebuilt a package with same NVR from epel with some fix for any reason, i understand that'd fail to import, right?
We just import all EPEL pkgs, keep all versions and people can tag the ones they need/want/have tested :-)
I'd expect also thhis would favor contributing fixes to EPEL that we'd just cross-tag in SIGs instead of forking.
-- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Jul 25, 2019, at 9:05 AM, Matthew Miller mattdm@mattdm.org wrote:
On Thu, Jul 25, 2019 at 02:17:39PM +0200, Alfredo Moralejo Alonso wrote:
Sorry, I'm not familiar with the process here. How does rebuilding help with testing? Doesn't it mean you have something _less_ tested?
What helps is not rebuilding packages (I'm fine with using EPEL packages if they are available) but publishing packages in SIG's managed repos instead of just enabling EPEL repos. I can test those builds (whether rebuilt or just cross-tagged) before tagging and pushing them to the actual repos.
Ah, that makes sense. I'm definitely in favor of figuring out how to do the cross-tagging here.
Has modularity worked yet for any project or person? I’m aware of it on RHEL 8, but so far it’s caused me nothing but interwoven dependency hell.
On Fri, Jul 26, 2019 at 08:02:09AM -0400, Nico Kadel-Garcia wrote:
Ah, that makes sense. I'm definitely in favor of figuring out how to do the cross-tagging here.
Has modularity worked yet for any project or person? I’m aware of it on RHEL 8, but so far it’s caused me nothing but interwoven dependency hell.
As an example, it's used to provide multiple versions of the crio-o runtime in Fedora.
On Fri, 26 Jul 2019 at 14:13, Matthew Miller mattdm@mattdm.org wrote:
On Fri, Jul 26, 2019 at 08:02:09AM -0400, Nico Kadel-Garcia wrote:
Ah, that makes sense. I'm definitely in favor of figuring out how to
do the
cross-tagging here.
Has modularity worked yet for any project or person? I’m aware of it on
RHEL 8, but so far it’s caused me nothing but interwoven dependency hell.
As an example, it's used to provide multiple versions of the crio-o runtime in Fedora.
I think Nico is dealing with the "I have ways to install systems which predate modules.. and my ways are running into "I can't install or build X now because Y is in a module and trying to install it broke Z""
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Fri, Jul 26, 2019 at 2:41 PM Stephen John Smoogen smooge@gmail.com wrote:
On Fri, 26 Jul 2019 at 14:13, Matthew Miller mattdm@mattdm.org wrote:
On Fri, Jul 26, 2019 at 08:02:09AM -0400, Nico Kadel-Garcia wrote:
Ah, that makes sense. I'm definitely in favor of figuring out how to do the cross-tagging here.
Has modularity worked yet for any project or person? I’m aware of it on RHEL 8, but so far it’s caused me nothing but interwoven dependency hell.
As an example, it's used to provide multiple versions of the crio-o runtime in Fedora.
I think Nico is dealing with the "I have ways to install systems which predate modules.. and my ways are running into "I can't install or build X now because Y is in a module and trying to install it broke Z""
Nico is working with "mock" on RHEL or CentOS 7, 8 and Fedora 30 to build leading edge versions of RPMs such as samba with full domain controller features enabled, awscli and botocore, and some recent work for awx. An OS built without modularity has no problems with packages written for modularity but built without it. It's the dependency chains among multiple modularity packages that wound up breaking things.
On Sun, 28 Jul 2019 at 15:34, Nico Kadel-Garcia nkadel@gmail.com wrote:
On Fri, Jul 26, 2019 at 2:41 PM Stephen John Smoogen smooge@gmail.com wrote:
On Fri, 26 Jul 2019 at 14:13, Matthew Miller mattdm@mattdm.org wrote:
On Fri, Jul 26, 2019 at 08:02:09AM -0400, Nico Kadel-Garcia wrote:
Ah, that makes sense. I'm definitely in favor of figuring out how
to do the
cross-tagging here.
Has modularity worked yet for any project or person? I’m aware of it
on RHEL 8, but so far it’s caused me nothing but interwoven dependency hell.
As an example, it's used to provide multiple versions of the crio-o
runtime
in Fedora.
I think Nico is dealing with the "I have ways to install systems which
predate modules.. and my ways are running into "I can't install or build X now because Y is in a module and trying to install it broke Z""
Nico is working with "mock" on RHEL or CentOS 7, 8 and Fedora 30 to
Smoogen should not put words into other people's mouths and instead say "Maybe we should ask what Nico is trying to do and why it is broken for him". Smoogen should learn his lesson on this but it is clear Smoogen needs a refresher course on manners.
build leading edge versions of RPMs such as samba with full domain controller features enabled, awscli and botocore, and some recent work for awx. An OS built without modularity has no problems with packages written for modularity but built without it. It's the dependency chains among multiple modularity packages that wound up breaking things. _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Il giorno mer 10 lug 2019 alle ore 22:53 Thomas Oulevey < 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.
-- Thomas Oulevey _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
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.
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 ?
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
On Fri, 12 Jul 2019 at 13:24, Niels de Vos ndevos@redhat.com wrote:
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.
I am laughing at this because one of the reasons why things like gluster and openstack are no longer available in EPEL was because they were moving too fast for users and we were getting complaints about those package changes being broken. And then we cause the same issue to gluster/openstack users because things in EPEL moved too quickly.
That said, I agree it is a problem and I am not saying people HAVE to use EPEL directly. I just want to make it possible that
1. You can use EPEL if you want, and not use EPEL if you want. 2. You can import src.rpm/spec files into CBS from EPEL as easily as possible. 3. You can get whatever fixes into EPEL so people who are doing things like mixing gluster and epel or openstack and epel aren't broken.
If those goals are useful and we can make that happen.. I will do what I can to make it happen.
Niels _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Fri, Jul 12, 2019 at 3:32 PM Stephen John Smoogen smooge@gmail.com wrote:
On Fri, 12 Jul 2019 at 13:24, Niels de Vos ndevos@redhat.com wrote:
I am laughing at this because one of the reasons why things like gluster and openstack are no longer available in EPEL was because they were moving too fast for users and we were getting complaints about those package changes being broken.--
I don't remember anyone complaining, per se, about this with GlusterFS.
What I do remember is that, independent of any complaints there may or may not have been, I retired GlusterFS in EPEL when Red Hat started shipping GlusterFS as a product, because EPEL policy stipulated that we could not ship packages that are/were in RHEL.
One issue we did have in EPEL was the inability to concurrently ship two or more major versions of GlusterFS for each of the actively maintained branches of GlusterFS; something that the CentOS Storage SIG does allow us to do. I.e. some people who were using, e.g., GlusterFS 3.4.x in production on RHEL/CentOS did not want to be forced to update their systems to GlusterFS 3.5.x, and then later on GlusterFS 3.6.x, 3.7.x, 3.8.x, and so on.
--
Kaleb
On Fri, 12 Jul 2019 at 19:28, Kaleb Keithley kkeithle@redhat.com wrote:
On Fri, Jul 12, 2019 at 3:32 PM Stephen John Smoogen smooge@gmail.com wrote:
On Fri, 12 Jul 2019 at 13:24, Niels de Vos ndevos@redhat.com wrote:
I am laughing at this because one of the reasons why things like gluster and openstack are no longer available in EPEL was because they were moving too fast for users and we were getting complaints about those package changes being broken.--
I don't remember anyone complaining, per se, about this with GlusterFS.
One of the issues I have with EPEL that I think the CentOS SIG's solves is the communication channels for products. If you 'break' someone you get the complaint to you. In EPEL products like openstack, gluster, etc end up pinging someone on the EPEL committee first to fix it for them... so most of the complaints when these things happen don't get to your team. This is one big reason I am not asking/begging etc to have gluster back in EPEL. It is not a good fit. You don't get what you want from us, and people don't communicate their problems to you.
What I do remember is that, independent of any complaints there may or may not have been, I retired GlusterFS in EPEL when Red Hat started shipping GlusterFS as a product, because EPEL policy stipulated that we could not ship packages that are/were in RHEL.
Yes. Parts of gluster got pulled into the channels we said we wouldn't overload.. and that made having it in EPEL not allowed.
One issue we did have in EPEL was the inability to concurrently ship two or more major versions of GlusterFS for each of the actively maintained branches of GlusterFS; something that the CentOS Storage SIG does allow us to do. I.e. some people who were using, e.g., GlusterFS 3.4.x in production on RHEL/CentOS did not want to be forced to update their systems to GlusterFS 3.5.x, and then later on GlusterFS 3.6.x, 3.7.x, 3.8.x, and so on.
Again completely agree with. This is not what EPEL is a good fit for without a lot of work. Supposedly this will all be fixable in our modular future... but that is a 2-3 year long journey fro anyone.
--
Kaleb
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Fri, Jul 12, 2019 at 03:31:05PM -0400, Stephen John Smoogen wrote:
On Fri, 12 Jul 2019 at 13:24, Niels de Vos ndevos@redhat.com wrote:
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.
I am laughing at this because one of the reasons why things like gluster and openstack are no longer available in EPEL was because they were moving too fast for users and we were getting complaints about those package changes being broken. And then we cause the same issue to gluster/openstack users because things in EPEL moved too quickly.
I do not remember seeing EPEL moving too quickly, but it is a possibility that needs to be accounted for. As for Gluster moving too quickly, see Kalebs reply.
That said, I agree it is a problem and I am not saying people HAVE to use EPEL directly. I just want to make it possible that
- You can use EPEL if you want, and not use EPEL if you want.
This requires all the dependencies to be part of the SIG repositories. Which is fine, but I am not sure if that was included in the original proposal (it mentioned build-roots though).
- You can import src.rpm/spec files into CBS from EPEL as easily as
possible. 3. You can get whatever fixes into EPEL so people who are doing things like mixing gluster and epel or openstack and epel aren't broken.
The last point might prove to be difficult. Not all EPEL maintainers care about features that CentOS offers (like pp64le support). Updating a library (+SONAME bump) would require rebuilds of several packages in EPEL. Requests like https://bugzilla.redhat.com/1410302 may get stalled because of the extra work that is involved (+BZ 1507090).
However, it would be ideal if EPEL and repositories from SIGs can co-exist without causing conflicts. I'd support any efforts for making this possible.
If those goals are useful and we can make that happen.. I will do what I can to make it happen.
Yes they are! Thanks for thinking about this problem and possible solutions, Niels
On Sat, Jul 13, 2019 at 5:03 AM Niels de Vos ndevos@redhat.com wrote:
On Fri, Jul 12, 2019 at 03:31:05PM -0400, Stephen John Smoogen wrote:
On Fri, 12 Jul 2019 at 13:24, Niels de Vos ndevos@redhat.com wrote:
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.
I am laughing at this because one of the reasons why things like gluster and openstack are no longer available in EPEL was because they were moving too fast for users and we were getting complaints about those package changes being broken. And then we cause the same issue to gluster/openstack users because things in EPEL moved too quickly.
I do not remember seeing EPEL moving too quickly, but it is a possibility that needs to be accounted for. As for Gluster moving too quickly, see Kalebs reply.
That said, I agree it is a problem and I am not saying people HAVE to use EPEL directly. I just want to make it possible that
- You can use EPEL if you want, and not use EPEL if you want.
This requires all the dependencies to be part of the SIG repositories. Which is fine, but I am not sure if that was included in the original proposal (it mentioned build-roots though).
- You can import src.rpm/spec files into CBS from EPEL as easily as
possible. 3. You can get whatever fixes into EPEL so people who are doing things like mixing gluster and epel or openstack and epel aren't broken.
The last point might prove to be difficult. Not all EPEL maintainers care about features that CentOS offers (like pp64le support). Updating a library (+SONAME bump) would require rebuilds of several packages in EPEL. Requests like https://bugzilla.redhat.com/1410302 may get stalled because of the extra work that is involved (+BZ 1507090).
To me, that's not a good excuse. You already are doing these builds in CBS, and it's easy because you're already here. Getting involved in EPEL isn't hard, and working with EPEL folks to get things (re)built as needed isn't difficult.
The only problems come up when there's a CentOS-only architecture. EPEL has never enabled CentOS architectures that don't exist in RHEL.
However, it would be ideal if EPEL and repositories from SIGs can co-exist without causing conflicts. I'd support any efforts for making this possible.
I sure hope so, since EPEL is a pretty popular addon repo for EL users. I've heard of people saying EL is useless without it. :P
The situation with SIGs in CentOS 7 is something I'd like to not see again for CentOS 8. The subtle breakages caused by SIGs doing different builds of EPEL packages made things more painful at times.
On Sat, Jul 13, 2019 at 6:57 AM Neal Gompa ngompa13@gmail.com wrote:
On Sat, Jul 13, 2019 at 5:03 AM Niels de Vos ndevos@redhat.com wrote:
On Fri, Jul 12, 2019 at 03:31:05PM -0400, Stephen John Smoogen wrote:
On Fri, 12 Jul 2019 at 13:24, Niels de Vos ndevos@redhat.com wrote:
To me, that's not a good excuse. You already are doing these builds in CBS, and it's easy because you're already here. Getting involved in EPEL isn't hard, and working with EPEL folks to get things (re)built as needed isn't difficult.
Easy or hard isn't the issue. Niels and I have been "involved in EPEL" in the past. GlusterFS was in EPEL once, and when it was, it used the EPEL userspace-rcu packages. (See my earlier email about why GlusterFS was retired in EPEL.)
I don't remember what the SIG policy was back when when Niels and I (but mainly Niels) moved GlusterFS to the Storage SIG, and I confess I'm ignorant about what the policy is now. AFAIK though, we still can't can't use EPEL to resolve build dependencies in CBS. (Pretty sure I could cobble up a .spec file that could accomplish it though.)
As an aside, I would assert that if EPEL really wanted to live up to its stated mission, it would – by now – be building packages for all the CentOS arches and not just the RHEL arches. Hint, hint.
If using EPEL for build dependencies is solved and the EPEL/CentOS architecture mismatch is resolved, off hand I can't think of any reason why we wouldn't be willing to use the EPEL userspace-rcu instead of building our own. Or I believe we'd at least be willing to consider it.
The only problems come up when there's a CentOS-only architecture.
EPEL has never enabled CentOS architectures that don't exist in RHEL.
Yes, that's definitely an issue. If we have to build userspace-rcu in CBS for ppc64le, then we might as well build it for the other arches too.
However, it would be ideal if EPEL and repositories from SIGs can co-exist without causing conflicts. I'd support any efforts for making this possible.
I sure hope so, since EPEL is a pretty popular addon repo for EL users. I've heard of people saying EL is useless without it. :P
There are certainly a lot of anecdotes around this. I don't find it to be the case for the things I work on.
Sometimes it's as simple as knowing what other repos and/or channels are available and using them. Including even knowing about them in the first place. E.g. the SCL; I guess some people just punt and install EPEL rather than figure out how to get and use SCL.
The situation with SIGs in CentOS 7 is something I'd like to not see
again for CentOS 8. The subtle breakages caused by SIGs doing different builds of EPEL packages made things more painful at times.
As far as the conflict between, e.g. the. userspace-rcu in the Storage SIG versus the one in EPEL, there are are some fairly simple solutions. It might be as easy as making sure the userspace-rcu in the Storage SIG always has a higher NVR than the one in EPEL. That does require some extra diligence to keep track of what's in EPEL If the userspace-rcu devs are careful to maintain API and ABI compatibility, then having a newer _version_ in the Storage SIG should be okay, in general.
If they're not good about ABI/API compatibility, then we can simply build/have the same _version_ as what's in EPEL, but build it with a higher _release_.
--
Kaleb
On Sat, Jul 13, 2019 at 8:06 AM Kaleb Keithley kkeithle@redhat.com wrote:
On Sat, Jul 13, 2019 at 6:57 AM Neal Gompa ngompa13@gmail.com wrote:
On Sat, Jul 13, 2019 at 5:03 AM Niels de Vos ndevos@redhat.com wrote:
On Fri, Jul 12, 2019 at 03:31:05PM -0400, Stephen John Smoogen wrote:
On Fri, 12 Jul 2019 at 13:24, Niels de Vos ndevos@redhat.com wrote:
To me, that's not a good excuse. You already are doing these builds in CBS, and it's easy because you're already here. Getting involved in EPEL isn't hard, and working with EPEL folks to get things (re)built as needed isn't difficult.
Easy or hard isn't the issue. Niels and I have been "involved in EPEL" in the past. GlusterFS was in EPEL once, and when it was, it used the EPEL userspace-rcu packages. (See my earlier email about why GlusterFS was retired in EPEL.)
I don't remember what the SIG policy was back when when Niels and I (but mainly Niels) moved GlusterFS to the Storage SIG, and I confess I'm ignorant about what the policy is now. AFAIK though, we still can't can't use EPEL to resolve build dependencies in CBS. (Pretty sure I could cobble up a .spec file that could accomplish it though.)
As an aside, I would assert that if EPEL really wanted to live up to its stated mission, it would – by now – be building packages for all the CentOS arches and not just the RHEL arches. Hint, hint.
If using EPEL for build dependencies is solved and the EPEL/CentOS architecture mismatch is resolved, off hand I can't think of any reason why we wouldn't be willing to use the EPEL userspace-rcu instead of building our own. Or I believe we'd at least be willing to consider it.
The only problems come up when there's a CentOS-only architecture. EPEL has never enabled CentOS architectures that don't exist in RHEL.
Yes, that's definitely an issue. If we have to build userspace-rcu in CBS for ppc64le, then we might as well build it for the other arches too.
The only architecture in CentOS not built in EPEL is armv7hl. EPEL builds ppc64le stuff all the time, since that's a RHEL architecture.
However, it would be ideal if EPEL and repositories from SIGs can co-exist without causing conflicts. I'd support any efforts for making this possible.
I sure hope so, since EPEL is a pretty popular addon repo for EL users. I've heard of people saying EL is useless without it. :P
There are certainly a lot of anecdotes around this. I don't find it to be the case for the things I work on.
Sometimes it's as simple as knowing what other repos and/or channels are available and using them. Including even knowing about them in the first place. E.g. the SCL; I guess some people just punt and install EPEL rather than figure out how to get and use SCL.
The situation with SIGs in CentOS 7 is something I'd like to not see again for CentOS 8. The subtle breakages caused by SIGs doing different builds of EPEL packages made things more painful at times.
As far as the conflict between, e.g. the. userspace-rcu in the Storage SIG versus the one in EPEL, there are are some fairly simple solutions. It might be as easy as making sure the userspace-rcu in the Storage SIG always has a higher NVR than the one in EPEL. That does require some extra diligence to keep track of what's in EPEL If the userspace-rcu devs are careful to maintain API and ABI compatibility, then having a newer _version_ in the Storage SIG should be okay, in general.
If they're not good about ABI/API compatibility, then we can simply build/have the same _version_ as what's in EPEL, but build it with a higher _release_.
Ugh, I hate these hacks... I wish we had sticky vendors in DNF for this, because playing EVR games is a poor experience for users...
On Sat, Jul 13, 2019 at 5:03 AM Niels de Vos ndevos@redhat.com wrote:
On Fri, Jul 12, 2019 at 03:31:05PM -0400, Stephen John Smoogen wrote:
On Fri, 12 Jul 2019 at 13:24, Niels de Vos ndevos@redhat.com wrote:
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.
I am laughing at this because one of the reasons why things like gluster and openstack are no longer available in EPEL was because they were moving too fast for users and we were getting complaints about those package changes being broken. And then we cause the same issue to gluster/openstack users because things in EPEL moved too quickly.
I do not remember seeing EPEL moving too quickly, but it is a possibility that needs to be accounted for. As for Gluster moving too quickly, see Kalebs reply.
I'm not sure if this is really centos-devel material, it might be more appropriate in an EPEL discussion list. That said, I've worked with clients whose need for stability far exceeded EPEL's need to provide leading edge tools. This includes clients unwilling to use the python36 tools, even though they were *much* easier to use than RHEL and CentOS supported SCLO tools.
That said, I agree it is a problem and I am not saying people HAVE to use EPEL directly. I just want to make it possible that
- You can use EPEL if you want, and not use EPEL if you want.
This requires all the dependencies to be part of the SIG repositories. Which is fine, but I am not sure if that was included in the original proposal (it mentioned build-roots though).
- You can import src.rpm/spec files into CBS from EPEL as easily as
possible. 3. You can get whatever fixes into EPEL so people who are doing things like mixing gluster and epel or openstack and epel aren't broken.
The last point might prove to be difficult. Not all EPEL maintainers care about features that CentOS offers (like pp64le support). Updating a library (+SONAME bump) would require rebuilds of several packages in EPEL. Requests like https://bugzilla.redhat.com/1410302 may get stalled because of the extra work that is involved (+BZ 1507090).
Yeah. The overlapping components of identical names is a booby trap waiting to start biting us, hard, even though it's precisely what we're seeing with RHEL 8 and the overlap of components in the highavailability, resilientstorage, and realtime software channels. The lack of a canonical repository for each package becomes.... awkward.
However, it would be ideal if EPEL and repositories from SIGs can co-exist without causing conflicts. I'd support any efforts for making this possible.
It's an old and tricky problem. If possible, I'd encourage using a distinct naming scheme for packages outside the EPEL repository, to distinguish them. It can be mitigated with "Provides:" and perhaps "Conflicts" statements. This is what IUS does, at https://ius.io/ . I've worked with them to provide updates for tools like the latest git release in the RHEL and CentOS environments. EPEL used this with python36 and python34, effectively. I suggest that it would be OK to do this for the various sigs and have alternative package names from EPEL.
Frankly, I wish EPEL would do this now for "ansible", which is now in RHEL channels and causes real contortions if EPEL i senabled on a RHEL host with ansible channels enabled.
Nico Kadel-Garcia
Il giorno ven 12 lug 2019 alle ore 18:59 Fabian Arrotin arrfab@centos.org ha scritto:
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 asexternal
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 ?
Works for me
-- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Fri, 12 Jul 2019 at 12:35, Johnny Hughes johnny@centos.org 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.
What happens if the CentOS OS package has changed or gone? Does CBS import them in so you can rely on a particular version of glibc etc?
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.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 12.07.19 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.
A few months ago inherited a installation of ovirt that was not getting much love for some more months. It was an ovirt 4.1.whatever. Upgrade process to 4.2 was a pain because if something fails at upgrade ovirt tries to rollback, but some requirements of ovirt 4.1 are not available anymore in centos repositories. Of course something failed...
I just want to point out that CentOS Project does it too! ovirt 4.1 dependencies only to be found in vault.centos.org
vault.centos.org was a pain within that context.
On Fri, Jul 12, 2019 at 11:35:39AM -0500, Johnny Hughes wrote:
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.
One thing that can help here is to not treat the EPEL maintainers as an opaque "they". It's actually people you can talk directly to, and who should have your concerns as a consumer in mind. You could even become a comaintainer of the package.
On 24/07/2019 19:53, Matthew Miller wrote:
On Fri, Jul 12, 2019 at 11:35:39AM -0500, Johnny Hughes wrote:
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.
One thing that can help here is to not treat the EPEL maintainers as an opaque "they". It's actually people you can talk directly to, and who should have your concerns as a consumer in mind. You could even become a comaintainer of the package.
The issue here is not related to maintainers of a given package, but rather one of EPEL policy whereby only the latest release of each package is available in the repository. As Johnny correctly mentions, this prevents EPEL users from performing a 'yum downgrade' when a package breaks as the old version is gone from the repository. Talking to the package maintainer or becoming a co-maintainer of a package isn't going to fix that.
So the question becomes why would you not want to allow your users the ability to yum downgrade a package that may be broken?
On Wed, 24 Jul 2019 at 16:51, Phil Perry pperry@elrepo.org wrote:
On 24/07/2019 19:53, Matthew Miller wrote:
On Fri, Jul 12, 2019 at 11:35:39AM -0500, Johnny Hughes wrote:
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.
One thing that can help here is to not treat the EPEL maintainers as an opaque "they". It's actually people you can talk directly to, and who
should
have your concerns as a consumer in mind. You could even become a comaintainer of the package.
The issue here is not related to maintainers of a given package, but rather one of EPEL policy whereby only the latest release of each
s/policy/buildsystem/
There isn't a policy about this beyond we use the tools we have, and those tools are built around composing a release.
package is available in the repository. As Johnny correctly mentions, this prevents EPEL users from performing a 'yum downgrade' when a package breaks as the old version is gone from the repository. Talking to the package maintainer or becoming a co-maintainer of a package isn't going to fix that.
So the question becomes why would you not want to allow your users the ability to yum downgrade a package that may be broken?
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Wed, Jul 24, 2019 at 4:59 PM Stephen John Smoogen smooge@gmail.com wrote:
On Wed, 24 Jul 2019 at 16:51, Phil Perry pperry@elrepo.org wrote:
On 24/07/2019 19:53, Matthew Miller wrote:
On Fri, Jul 12, 2019 at 11:35:39AM -0500, Johnny Hughes wrote:
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.
One thing that can help here is to not treat the EPEL maintainers as an opaque "they". It's actually people you can talk directly to, and who should have your concerns as a consumer in mind. You could even become a comaintainer of the package.
The issue here is not related to maintainers of a given package, but rather one of EPEL policy whereby only the latest release of each
s/policy/buildsystem/
There isn't a policy about this beyond we use the tools we have, and those tools are built around composing a release.
Specifically, Bodhi pulls all the latest updates marked for stable or are stable and sucks them in to produce a repository. It doesn't work like dist-repos where you can tag in multiple EVRs of a package to push out. Maybe one day this will be fixed, but I'm not sure that's anytime soon...
On Wed, Jul 24, 2019 at 09:43:20PM +0100, Phil Perry wrote:
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.
One thing that can help here is to not treat the EPEL maintainers as an opaque "they". It's actually people you can talk directly to, and who should have your concerns as a consumer in mind. You could even become a comaintainer of the package.
The issue here is not related to maintainers of a given package, but rather one of EPEL policy whereby only the latest release of each package is available in the repository. As Johnny correctly
I disagree! The quote is "they change the versions out". If you're not ready for the version to be changed, coordinate with the maintainer. As I mentioned elsewhere, I hope that in the future with EPEL 8 with modularity enabled, you'd even have the option of having the old version available in parallel.
On Thu, Jul 25, 2019 at 9:04 AM Matthew Miller mattdm@mattdm.org wrote:
On Wed, Jul 24, 2019 at 09:43:20PM +0100, Phil Perry wrote:
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.
One thing that can help here is to not treat the EPEL maintainers as an opaque "they". It's actually people you can talk directly to, and who should have your concerns as a consumer in mind. You could even become a comaintainer of the package.
The issue here is not related to maintainers of a given package, but rather one of EPEL policy whereby only the latest release of each package is available in the repository. As Johnny correctly
I disagree! The quote is "they change the versions out". If you're not ready for the version to be changed, coordinate with the maintainer. As I mentioned elsewhere, I hope that in the future with EPEL 8 with modularity enabled, you'd even have the option of having the old version available in parallel.
Keeping old versions around is more of a Bodhi problem. If it had an option to keep old versions when it recomposed the EPEL repos, then it'd be fine.
On Thu, Jul 25, 2019 at 09:07:07AM -0400, Neal Gompa wrote:
I disagree! The quote is "they change the versions out". If you're not ready for the version to be changed, coordinate with the maintainer. As I mentioned elsewhere, I hope that in the future with EPEL 8 with modularity enabled, you'd even have the option of having the old version available in parallel.
Keeping old versions around is more of a Bodhi problem. If it had an option to keep old versions when it recomposed the EPEL repos, then it'd be fine.
It depends on _why_ there's a new version. If the new version is an API change and the consumer wants to keep the old line for compatibility, just pinning to an old release means you're not able to do bug fixes or security updates. If that's expected to be a long-term situation, a module would make sense then.
On Thu, 25 Jul 2019 at 09:15, Matthew Miller mattdm@mattdm.org wrote:
On Thu, Jul 25, 2019 at 09:07:07AM -0400, Neal Gompa wrote:
I disagree! The quote is "they change the versions out". If you're not
ready
for the version to be changed, coordinate with the maintainer. As I mentioned elsewhere, I hope that in the future with EPEL 8 with
modularity
enabled, you'd even have the option of having the old version
available in
parallel.
Keeping old versions around is more of a Bodhi problem. If it had an option to keep old versions when it recomposed the EPEL repos, then it'd be fine.
It depends on _why_ there's a new version. If the new version is an API change and the consumer wants to keep the old line for compatibility, just pinning to an old release means you're not able to do bug fixes or security updates. If that's expected to be a long-term situation, a module would make sense then.
So I don't think that is possible without even more investment in the EPEL infrastructure. It means our tooling and our mirrors have to keep 'dead' modules around as much as 'dead' packages. Yes you are pinning to an old module but if it is no longer in the downloads or mirrors then it is just as unavailable as if the RPM you needed for your enterprise is no longer in the EPEL repo.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Thu, Jul 25, 2019 at 09:25:53AM -0400, Stephen John Smoogen wrote:
It depends on _why_ there's a new version. If the new version is an API change and the consumer wants to keep the old line for compatibility, just pinning to an old release means you're not able to do bug fixes or security updates. If that's expected to be a long-term situation, a module would make sense then.
So I don't think that is possible without even more investment in the EPEL infrastructure. It means our tooling and our mirrors have to keep 'dead' modules around as much as 'dead' packages. Yes you are pinning to an old module but if it is no longer in the downloads or mirrors then it is just as unavailable as if the RPM you needed for your enterprise is no longer in the EPEL repo.
I'm not suggesting the module would be "dead". Instead, because SIG consumer needs a certain version, and there is demand for a newer version from other consumers (or just interest in providing it), rather than maintaining that other version in a separate SIG repo, it could be maintained in EPEL as a module stream. Probably a very low-maintenance one, but there would still be the possibility of bug-fixes or security patches, or perhaps even updating to an API-compatible x.y.z release of the older x.y.
On 10/07/2019 21:52, Thomas Oulevey wrote:
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 !
@SIGs, take below as an opinion piece only.
I've chimed in a number of times in various places, probably I'm not the only one(as non-devel) who suggested - stop with all that SIG nonsense.
Every SIG pretty much, that's what user/admin experience historically proved, spends time each locked up in own SIG room and there is no world beyond it. And it works all great, and things there get fixed and improved, etc.. fantastic if it wasn't for all duplicated packages and conflicts which for "regular" users is a massive nuisance, and having multiple repos becomes almost a public enemy no.1.
Have EPEL (which almost everybody begin with, is a must-have) and then let's say try centos-openstack-some/one, while having R packages, maybe add octave, nothing too fancy and not too many of it - you will get conflicts right away. Want something little more fancy - openVswitch - and more.. hmmm.
And if one has some SIG repos enabled then one hardly ever see EPEL, which SIGs here seem to be most worried about, releases new versions which would relieve old packages, it's rather SIGs conflicting packages which march at faster pace towards newest package version (and which could go(back) to EPEL)
And we are not even frustrated anymore for in years each who needs extra bits probably have his/her workarounds worked out and get things which must have but I, and probably many other "regular" users, will repeat this again - put it all together and work closer together, find a way somehow. SIGs have a plenty to offer and what they offer EPEL should not diminish nor underestimate. If both could work together as one then that would save time & man-hours for everyone, also would make lives of end-users/admins everywhere much easier.
many thank & lots love, L.
-
Alfredo Moralejo Alonso -
Brian Stinson -
Fabian Arrotin -
Johnny Hughes -
Kaleb Keithley -
lejeczek -
Markus Falb -
Matthew Miller -
Neal Gompa -
Nico Kadel-Garcia -
Niels de Vos -
Pablo Sebastián Greco -
Pat Riehecky -
Phil Perry -
Sandro Bonazzola -
Stephen John Smoogen -
Thomas Oulevey