On Wed, Mar 23, 2022 at 2:54 PM Carl George <carl@xxxxxxxxxx> wrote: > > On Mon, Mar 14, 2022 at 4:23 PM Troy Dawson <tdawson@xxxxxxxxxx> wrote: > > > > > > > > On Thu, Mar 10, 2022 at 2:17 PM Diego Herrera <dherrera@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > 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@xxxxxxxxxxxxxxxxxxxxxxx > > 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_dependencies > > 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 _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
