packages present in Fedora - ELN HighAvailability repository not present in content resolver

[hroncok]

Reopened from fedora-eln/content-resolver#81

The following repo from fedora-repos-eln-41-1.noarch:

[eln-ha]
name=Fedora - ELN HighAvailability - Developmental packages for the next Enterprise Linux release
baseurl=https://odcs.fedoraproject.org/composes/production/latest-Fedora-ELN/compose/HighAvailability/$basearch/os/
#metalink=https://mirrors.fedoraproject.org/metalink?repo=eln&arch=$basearch
enabled=0
countme=1
metadata_expire=6h
repo_gpgcheck=0
type=rpm
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-eln-$basearch
skip_if_unavailable=False

[eln-ha-source]
name=Fedora - ELN HighAvailability - Source
baseurl=https://odcs.fedoraproject.org/composes/production/latest-Fedora-ELN/compose/HighAvailability/source/tree/
#metalink=https://mirrors.fedoraproject.org/metalink?repo=eln-source&arch=$basearch
enabled=0
metadata_expire=6h
repo_gpgcheck=0
type=rpm
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-eln-$basearch
skip_if_unavailable=False

Packages from this repo do not exist at https://tiny.distro.builders/view-srpm--view-eln--xxx.html

For example (components):

• amtterm
• google-api-python-client
• google-auth-httplib2
• python-msrest
• re2
• rubygem-tilt
• rubygem-nio4r

But also many others.

cc @frenzymadness

@yselkowitz said:

This is not due to a bug in CR itself. fence-agents is listed as a placeholder in ELN proper, but either because it is a real package in Fedora (just built very differently for CS/RHEL) and/or because it is also listed as a real package in an ELN Extras workload, it is being rebuilt in ELN, and then included in ELN composes because of comps listings.

As for HA in general and how to resolve this difference, the ELN tracker would be the place to discuss this. This issue can't be transferred there (different orgs), so please re-file there if needed.

[hroncok]

The problem this causes is the following:

• There are dozens of packages included in ELN.
• Content resolver does not list the reason for them.

We want to assign the maintainership of those packages for future RHELs to the owners of the dependents, but without a content resolver page to look at, we lack the visible data to support it.

Naive assumptions by me (contradicting the current reality):

• If such placeholder-dependent packages won't be fokred for c11s, they should not be in ELN.
• If such placeholder-dependent packages will be fokred for c11s, they should be in content resolver.

[yselkowitz]

The ELN view in CR is the definitive list of packages in ELN (and hence on track to be forked in c11s). The packages you mention are unwanted and are only included in ELN composes due to a fluke. Therefore, owners should not be assigned to them.

When there are differences between CR and the compose, we should of course resolve those. In this case, the question is how exactly to do so, but ultimately they don't belong.

[hroncok]

For the record, here are the packages we know about:

fence-agents brings in amtterm, google-api-python-client, google-auth-httplib2, grpc, perl-Convert-BinHex, perl-Email-Date-Format, perl-IO-SessionData, perl-MIME-Lite, perl-MIME-Types, perl-MIME-tools, perl-SOAP-Lite, python-adal, python-azure-common, python-azure-core, python-azure-identity, python-azure-mgmt-compute, python-azure-mgmt-core, python-azure-mgmt-network, python-boto3, python-botocore, python-cachetools, python-certifi, python-debtcollector, python-google-api-core, python-google-auth, python-googleapis-common-protos, python-httplib2, python-iso8601, python-isodate, python-jwt, python-keystoneauth1, python-msal, python-msal-extensions, python-msgpack, python-msrest, python-msrestazure, python-netifaces, python-novaclient, python-os-service-types, python-oslo-i18n, python-oslo-serialization, python-oslo-utils, python-pbr, python-portalocker, python-rsa, python-s3transfer, python-stevedore, python-suds, python-uritemplate, python-wrapt, pytz, re2

pcs brings in rubygem-backports, rubygem-childprocess, rubygem-ethon, rubygem-ffi, rubygem-mustermann, rubygem-nio4r, rubygem-puma, rubygem-rack, rubygem-rack-protection, rubygem-sinatra, rubygem-tilt

python-pycurl is brought in by both and complicetes the two dependency graphs even further

[yselkowitz]

Possible "fixes" for this would be:

1. Maintain an eln branch (possibly based on c10s) of these (supposed) placeholder packages, and build those for ELN (and convert the placeholders to real packages)
2. OR exclude these packages from the HA compose, which wouldn't leave much left there (they would then move to ELN Extras, as they are listed there)
3. OR leave the status quo as a known "issue" (there would at least be content in HA, and the package list in CR is correct, but it's confusing).

[hroncok]

Perhaps if the packages from HA are not forked from Fedora (but from the previous CentOS Stream version instead), tracking them in ELN makes little sense. If that's the case, I'd go with option 2 as it requires less work.

[yselkowitz]

The community members of the ELN SIG have no particular need for these builds to be in HA, and since EPEL is allowed to conflict with HA, they're just as happy for the builds to land in ELN Extras instead. It'll probably be a few weeks before I can work on this though.