There does not appear to be an explicit conflict policy for EPEL8:
https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_...
I got a report against python3-s3transfer and python3-botocore conflicting with the CentOS 8 HighAvailability repo. No idea if this is an issue or not: https://bugzilla.redhat.com/show_bug.cgi?id=1821630
It looks like we have avoided conflicts with the "ha" repos in the past, and I can enable the rhel-8-for-x86_64-highavailability-rpms repo on my RHEL8 developer license machine so it does seem available to everyone.
On 4/8/20 7:20 PM, Orion Poplawski wrote:
There does not appear to be an explicit conflict policy for EPEL8:
https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_...
I got a report against python3-s3transfer and python3-botocore conflicting with the CentOS 8 HighAvailability repo. No idea if this is an issue or not: https://bugzilla.redhat.com/show_bug.cgi?id=1821630
It looks like we have avoided conflicts with the "ha" repos in the past, and I can enable the rhel-8-for-x86_64-highavailability-rpms repo on my RHEL8 developer license machine so it does seem available to everyone.
yum list --showduplicates | awk '$1 == lastpkg && (lastrepo == "epel" || $3 == "epel" ) { print $0; print last;}; { last = $0; lastpkg = $1; lastrepo = $3 };'
Other conflicts with HA:
python3-boto3.noarch 1.10.21-1.el8 epel python3-boto3.noarch 1.6.1-2.el8
rhel-8-for-x86_64-highavailability-rpms python3-botocore.noarch 1.13.21-1.el8 epel python3-botocore.noarch 1.9.1-2.el8
rhel-8-for-x86_64-highavailability-rpms python3-fasteners.noarch 0.14.1-20.el8 epel python3-fasteners.noarch 0.14.1-14.el8
rhel-8-for-x86_64-highavailability-rpms python3-google-api-client.noarch 1:1.6.7-10.el8 epel python3-google-api-client.noarch 1.6.5-3.el8
rhel-8-for-x86_64-highavailability-rpms python3-oauth2client.noarch 4.1.3-9.el8 epel python3-oauth2client.noarch 4.1.2-6.el8
rhel-8-for-x86_64-highavailability-rpms python3-s3transfer.noarch 0.2.1-1.el8 epel python3-s3transfer.noarch 0.1.13-1.el8
rhel-8-for-x86_64-highavailability-rpms python3-uritemplate.noarch 3.0.0-10.el8 epel python3-uritemplate.noarch 3.0.0-3.el8
rhel-8-for-x86_64-highavailability-rpms
With appstream:
python3-psutil.x86_64 5.6.3-5.el8 epel python3-psutil.x86_64 5.4.3-10.el8 rhel-8-for-x86_64-appstream-rpms
From 8.2 beta:
dwarves.x86_64 1.15-5.el8 codeready-builder-beta-for-rhel-8-x86_64-rpms dwarves.x86_64 1.15-4.el8 epel
libzstd.x86_64 1.4.4-1.el8 epel libzstd.x86_64 1.4.2-2.el8 rhel-8-for-x86_64-baseos-beta-rpms libzstd-devel.x86_64 1.4.4-1.el8 epel libzstd-devel.x86_64 1.4.2-2.el8 rhel-8-for-x86_64-baseos-beta-rpms perl-Convert-ASN1.noarch 0.27-17.el8 rhel-8-for-x86_64-appstream-beta-rpms perl-Convert-ASN1.noarch 0.27-16.el8 epel perl-LDAP.noarch 1:0.66-7.el8 rhel-8-for-x86_64-appstream-beta-rpms perl-LDAP.noarch 1:0.66-5.el8 epel
python3-psutil.x86_64 5.6.3-5.el8 epel python3-psutil.x86_64 5.4.3-10.el8 rhel-8-for-x86_64-appstream-beta-rpms
whois.x86_64 5.5.1-2.el8 rhel-8-for-x86_64-appstream-beta-rpms whois.x86_64 5.5.1-1.el8 epel whois-nls.noarch 5.5.1-2.el8 rhel-8-for-x86_64-appstream-beta-rpms whois-nls.noarch 5.5.1-1.el8 epel zstd.x86_64 1.4.4-1.el8 epel zstd.x86_64 1.4.2-2.el8 rhel-8-for-x86_64-appstream-beta-rpms
On Wed, Apr 8, 2020, at 9:20 PM, Orion Poplawski wrote:
There does not appear to be an explicit conflict policy for EPEL8:
https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_...
I got a report against python3-s3transfer and python3-botocore conflicting with the CentOS 8 HighAvailability repo. No idea if this is an issue or not: https://bugzilla.redhat.com/show_bug.cgi?id=1821630
It looks like we have avoided conflicts with the "ha" repos in the past, and I can enable the rhel-8-for-x86_64-highavailability-rpms repo on my RHEL8 developer license machine so it does seem available to everyone.
It's not available to everyone. It's a paid add-on. My understanding is that EPEL avoids conflicting only with the BaseOS, AppStream, and CodeReady Linux Builder repositories.
c.f., ansible, which is more widely available than HA, but also carried in EPEL.
V/r, James Cassell
On Wed, Apr 8, 2020 at 11:26 PM James Cassell fedoraproject@cyberpear.com wrote:
On Wed, Apr 8, 2020, at 9:20 PM, Orion Poplawski wrote:
There does not appear to be an explicit conflict policy for EPEL8:
https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_...
I got a report against python3-s3transfer and python3-botocore conflicting with the CentOS 8 HighAvailability repo. No idea if this is an issue or not: https://bugzilla.redhat.com/show_bug.cgi?id=1821630
It looks like we have avoided conflicts with the "ha" repos in the past, and I can enable the rhel-8-for-x86_64-highavailability-rpms repo on my RHEL8 developer license machine so it does seem available to everyone.
It's not available to everyone. It's a paid add-on. My understanding is that EPEL avoids conflicting only with the BaseOS, AppStream, and CodeReady Linux Builder repositories.
c.f., ansible, which is more widely available than HA, but also carried in EPEL.
One addendum to this: EPEL 8 *may* provide conflicting content in non-default module streams (since enabling these is always opt-in).
On Wed, 8 Apr 2020 at 21:21, Orion Poplawski orion@nwra.com wrote:
There does not appear to be an explicit conflict policy for EPEL8:
https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_...
I got a report against python3-s3transfer and python3-botocore conflicting with the CentOS 8 HighAvailability repo. No idea if this is an issue or not: https://bugzilla.redhat.com/show_bug.cgi?id=1821630
It looks like we have avoided conflicts with the "ha" repos in the past, and I can enable the rhel-8-for-x86_64-highavailability-rpms repo on my RHEL8 developer license machine so it does seem available to everyone
When EPEL-8 was getting set up, HA was a paid add-on for EL8 and so not available in the developer license. EPEL therefore did not conflict against it or use it as a 'you can't build this in EPEL'. EPEL will end up conflicting with some RHEL channels.. but since there is no 'Requires: Conflicts:' in repo land we can't do much about it.
epel-devel@lists.fedoraproject.org
-
James Cassell -
Orion Poplawski -
Stephen Gallagher -
Stephen John Smoogen