On Wed, Mar 23, 2022 at 2:54 PM Carl George <carl(a)redhat.com> wrote:
On Mon, Mar 14, 2022 at 4:23 PM Troy Dawson <tdawson(a)redhat.com> wrote:
>
>
>
> On Thu, Mar 10, 2022 at 2:17 PM Diego Herrera <dherrera(a)redhat.com> wrote:
>>
>> I've been checking the packages that won't install on EPEL [1] and found
out that drbd-pacemaker cant get installed
>> because of a missing dependency (pacemaker). While researching why, I saw that
pacemaker exists on EPEL7 because it's
>> provided by the HighAvailability repo, but by policy [2] that repo is not a base
for EPEL8 nor EPEL9.
>>
>> When I asked on how to handle this cases on the steering meeting, some proposed
ideas were:
>>
>> * Rebuild the dependencies as -epel
>> * Retire the packages
>> * Bringing back HA & RS repo
>>
>> The only other package that i've found also has this problem is resalloc-aws
that depends on awscli.
>>
>> Is there a policy on this cases? Are EPEL packages allowed to require packages
outside of the policy approved?
>> I would like more feedback on how to proceed so we can file bugs for this
packages correctly.
>>
>> Package: drbd-pacemaker-9.20.2-1.el9
>> Error: Problem: conflicting requests - nothing provides pacemaker needed by
drbd-pacemaker-9.20.2-1.el9.x86_64
>>
>> Package: resalloc-aws-1.1-1.el9
>> Error: Problem: conflicting requests - nothing provides awscli needed by
resalloc-aws-1.1-1.el9.noarch
>>
>> Package: drbd-pacemaker-9.17.0-1.el8
>> Error: Problem: conflicting requests - nothing provides pacemaker needed by
drbd-pacemaker-9.17.0-1.el8.x86_64
>>
>> [1]
https://tdawson.fedorapeople.org/epel/willit/epel8/status-wont-install.html
>> [2]
https://docs.fedoraproject.org/en-US/epel/epel-policy/#_policy
>
>
> Someone can tell me I'm wrong, but I believe if something is in HA or RS in
RHEL8 or 9 it is fair game for EPEL8 or EPEL9.
> Those packages are currently not being excluded when you request a package for epel8
or epel9.
>
> So, my opinion, build pacemaker in EPEL.
>
> Troy
>
> _______________________________________________
> epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproj...
> Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Typically EPEL inherits policy from Fedora, diverging when necessary.
Here is the corresponding section of Fedora policy.
"All package dependencies (build-time or runtime, regular, weak or
otherwise) MUST ALWAYS be satisfiable within the official Fedora
repositories."
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_package_depen...
We don't consider HA or RS part of the base RHEL distribution
(referred to in policy as the "Target Base"). However, I don't think
we should strictly forbid any dependency on HA or RS packages, because
that would require unnecessary duplication of HA/RS packages in EPEL
(which is allowed, but shouldn't be required IMO). I suggest a
compromise that we can make the policy:
"All EPEL package dependencies (build-time or runtime) MUST ALWAYS be
satisfiable within the Target Base or EPEL itself. Weak package
dependencies are allowed on packages from additional RHEL channels
that are not part of the Target Base, such as the HighAvailability
channel."
--
Carl George
We discussed this a bit further at today's EPEL Steering Committee.
One alternative that was suggested was to just add the HA and RS repos
to the target base list. The initial impact of that would be that
several packages already in EPEL8 would become policy violations and
would have to be retired.
HA8 package
EPEL8 package
awscli-1.14.50-5.el8
awscli-1.18.156-1.el8
google-api-python-client-1.6.5-3.el8
google-api-python-client-1.6.7-10.el8
python-boto3-1.6.1-2.el8
python-boto3-1.15.15-1.el8
python-botocore-1.9.1-2.el8
python-botocore-1.18.15-1.el8
python-fasteners-0.14.1-14.el8
python-fasteners-0.14.1-20.el8
python-oauth2client-4.1.2-6.el8
python-oauth2client-4.1.3-9.el8
python-s3transfer-0.1.13-1.el8
python-s3transfer-0.3.4-1.el8
python-uritemplate-3.0.0-3.el8
python-uritemplate-3.0.0-10.el8
Two of these are the same version (but higher release) than what's in
HA/RS. The other six are newer versions, so retiring them in favor of
the HA/RS package would result in version downgrades. All eight will
require users do a distrosync instead of an upgrade to switch to a
maintained package. Further complicating the matter, four of the
eight packages are x86_64 only. Retiring them will create the need
for <package>-epel variants for the missing architectures. RS is
mostly the same content as HA, with some additional packages that
currently do not overlap with EPEL, but do note that RS is not
available for aarch64, so EPEL packages would need to `ExcludeArch:
aarch64` if they need to depend on those additional packages (cmirror
and dlm in RS8; ctdb, dlm, and gfs2-utils in RS9).
Another aspect to consider is that allowing non-weak dependencies on
channels that are disabled by default results in a bad user
experience. We already see this happen dependencies in CRB. Adding
more channels this can happen with would make the user experience
worse. In addition to being disabled by default, not all RHEL
subscriptions include access to these channels.
--
Carl George