On 23/04/2020 19:12, lejeczek via CentOS-devel wrote:
Hi guys,
Here some bits being in collision:
virglrenderer.src 0.6.0-5.20180814git491d3b705.el8 advanced-virt virglrenderer.x86_64 0.6.0-5.20180814git491d3b705.el8 advanced-virt virglrenderer.x86_64 0.8.0-1.20191002git4ac3a04c.el8 epel
Please push as much as you can over to EPEL. It's way to often that EPEL gets unnecessary confronted by extras/third-parties repos while it should be taken advantage of.
I disagree here. If something is in centos repos (or RHEL for that matter), the package should not be in epel.
Matthias
On Fri, Apr 24, 2020 at 7:23 AM Matthias Runge mrunge@matthias-runge.de wrote:
On 23/04/2020 19:12, lejeczek via CentOS-devel wrote:
Hi guys,
Here some bits being in collision:
virglrenderer.src 0.6.0-5.20180814git491d3b705.el8 advanced-virt virglrenderer.x86_64 0.6.0-5.20180814git491d3b705.el8 advanced-virt virglrenderer.x86_64 0.8.0-1.20191002git4ac3a04c.el8 epel
Please push as much as you can over to EPEL. It's way to often that EPEL gets unnecessary confronted by extras/third-parties repos while it should be taken advantage of.
I disagree here. If something is in centos repos (or RHEL for that matter), the package should not be in epel.
SIG repos do not qualify here. As SIG repos can do basically anything, including override CentOS base packages, it's not a mark to block inclusion in EPEL. They also don't necessarily map cleanly to RHEL content, either.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Fri, Apr 24, 2020 at 1:44 PM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Apr 24, 2020 at 7:23 AM Matthias Runge mrunge@matthias-runge.de wrote:
On 23/04/2020 19:12, lejeczek via CentOS-devel wrote:
Hi guys,
Here some bits being in collision:
virglrenderer.src 0.6.0-5.20180814git491d3b705.el8 advanced-virt virglrenderer.x86_64 0.6.0-5.20180814git491d3b705.el8 advanced-virt virglrenderer.x86_64 0.8.0-1.20191002git4ac3a04c.el8 epel
Please push as much as you can over to EPEL. It's way to often that
EPEL
gets unnecessary confronted by extras/third-parties repos while it should be taken advantage of.
I disagree here. If something is in centos repos (or RHEL for that matter), the package should not be in epel.
SIG repos do not qualify here. As SIG repos can do basically anything, including override CentOS base packages, it's not a mark to block inclusion in EPEL. They also don't necessarily map cleanly to RHEL content, either.
CloudSIG repos are not created nor tested to work with EPEL. Among other reasons CloudSIG support several stable releases which require different dependencies versions and EPEL is single rolling release.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 24/04/2020 12:54, Alfredo Moralejo Alonso wrote:
On Fri, Apr 24, 2020 at 1:44 PM Neal Gompa <ngompa13@gmail.com mailto:ngompa13@gmail.com> wrote:
On Fri, Apr 24, 2020 at 7:23 AM Matthias Runge <mrunge@matthias-runge.de <mailto:mrunge@matthias-runge.de>> wrote: > > On 23/04/2020 19:12, lejeczek via CentOS-devel wrote: > > Hi guys, > > > > Here some bits being in collision: > > > > virglrenderer.src > > 0.6.0-5.20180814git491d3b705.el8 > > advanced-virt > > virglrenderer.x86_64 > > 0.6.0-5.20180814git491d3b705.el8 > > advanced-virt > > virglrenderer.x86_64 > > 0.8.0-1.20191002git4ac3a04c.el8 epel > > > > Please push as much as you can over to EPEL. It's way to often that EPEL > > gets unnecessary confronted by extras/third-parties repos while it > > should be taken advantage of. > > > > I disagree here. If something is in centos repos (or RHEL for that > matter), the package should not be in epel. > SIG repos do not qualify here. As SIG repos can do basically anything, including override CentOS base packages, it's not a mark to block inclusion in EPEL. They also don't necessarily map cleanly to RHEL content, either.CloudSIG repos are not created nor tested to work with EPEL.
Yet they should be. Everything should be tested and should take as much advantage of EPEL as possible, as EPEL is for almost every "regular" scientific/small,large/business/education - and whichever other names one could come up with - environment, the must-have repo. If SIGs do not start crawling out their "special" closets and do not work with EPEL tightly then the rest of us will continue to suffer constant packages conflicts. Stuff collides way too often! Or rid of EPEL altogether and just give us a consistent & stable software repositories.
Among other reasons CloudSIG support several stable releases which require different dependencies versions and EPEL is single rolling release.
-- 真実はいつも一つ！/ 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
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 24/04/2020 15:59, lejeczek via CentOS-devel wrote:
CloudSIG repos are not created nor tested to work with EPEL.
Yet they should be. Everything should be tested and should take as much advantage of EPEL as possible, as EPEL is for almost every "regular" scientific/small,large/business/education - and whichever other names one could come up with - environment, the must-have repo. If SIGs do not start crawling out their "special" closets and do not work with EPEL tightly then the rest of us will continue to suffer constant packages conflicts. Stuff collides way too often! Or rid of EPEL altogether and just give us a consistent & stable software repositories.
Among other reasons CloudSIG support several stable releases which require different dependencies versions and EPEL is single rolling release.
There is a reason for not including EPEL in e.g CloudSig or Opstools: EPEL is not gated and as Alfredo already mentioned, a rolling release.
There was a time when cloud SIG relied on EPEL, but e.g an all test days we organized for real people to test new deployments, then EPEL was broken; for various reasons: person a upgraded puppet, person b pushed a broken build, etc. etc. Coming from that experience, I would not pull it in and rather contribute to a CentOS SIG to have more control on the content; it is easier and more reliable to handle upgrades there.
IMHO EPEL is something you can use; but if you do, understand that every fedora packager can push their packages to EPEL. There are rules, but not all packagers care about the upgrade policy. I totally understand, where you are coming from, but EPEL is too unstable in my experience.
Matthias
On 24/04/2020 12:54, Alfredo Moralejo Alonso wrote:
On Fri, Apr 24, 2020 at 1:44 PM Neal Gompa <ngompa13@gmail.com mailto:ngompa13@gmail.com> wrote:
On Fri, Apr 24, 2020 at 7:23 AM Matthias Runge <mrunge@matthias-runge.de <mailto:mrunge@matthias-runge.de>> wrote: > > On 23/04/2020 19:12, lejeczek via CentOS-devel wrote: > > Hi guys, > > > > Here some bits being in collision: > > > > virglrenderer.src > > 0.6.0-5.20180814git491d3b705.el8 > > advanced-virt > > virglrenderer.x86_64 > > 0.6.0-5.20180814git491d3b705.el8 > > advanced-virt > > virglrenderer.x86_64 > > 0.8.0-1.20191002git4ac3a04c.el8 epel > > > > Please push as much as you can over to EPEL. It's way to often that EPEL > > gets unnecessary confronted by extras/third-parties repos while it > > should be taken advantage of. > > > > I disagree here. If something is in centos repos (or RHEL for that > matter), the package should not be in epel. > SIG repos do not qualify here. As SIG repos can do basically anything, including override CentOS base packages, it's not a mark to block inclusion in EPEL. They also don't necessarily map cleanly to RHEL content, either.CloudSIG repos are not created nor tested to work with EPEL. Among other reasons CloudSIG support several stable releases which require different dependencies versions and EPEL is single rolling release.
-- 真実はいつも一つ！/ 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
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
EPEL repo provides modularity already, there is 'epel-modular'. I have not doubts that it's just a simple matter of "not giving a toss" and if involved parties only had the incline to get a little closer together, then all the conflicts and collisions of packages could be resolved very quickly.
regards, L.
-
Alfredo Moralejo Alonso -
lejeczek -
Matthias Runge -
Neal Gompa