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 _______________________________________________ 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
