On Thu, Mar 24, 2022 at 5:50 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > On Wed, Mar 23, 2022 at 09:18:08PM -0500, Carl George wrote: > > On Wed, Mar 23, 2022 at 2:54 PM Carl George <carl@xxxxxxxxxx> wrote: > > > > > > 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 > > Well, for 8 and 9... for 7 we do. ;) > > > > 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. > > Yeah, I guess thats pretty anoying in 8 since we didn't start with them. > ;( > > So, if we did allow weak deps to packages in other non our Base repos, > wouldn't that not actually work for the case that started this thread? > > ie, say I have a foo-plugin package and foo is in a different non epel > base rhel channel and I add a Reccomends for it in epel. People who have > the channel enabled would be fine but if someone else installed > foo-plugin it would just... not work. What I suggested as policy would be to allow weak dependencies on non-base channels, not to incorrectly identify all hard dependencies as weak if they're in these channels. If an EPEL package has a hard dependency, that dependency should be in the target base or EPEL itself. If the dependency actually is weak (optional), it would be useful to allow those to be provided by non-target-base channels. The plugin example is a bit of a grey area. If the software is designed as such that no one uses the plugin directly, but rather the plugin extends the functionality of the main software which is used directly, then I think users can figure out they need to install both the main software and the plugin, regardless of the dependency relationship. This will vary case by case, and we could allowed these by Steering Committee exception only. > > Also could we tell if deps changed? Say I have foo-plugin in epel > Reccommending foo, and RHEL drops foo. None of our 'will it install' or > broken deps type checks will know that it is now not working. ;( As far as I know RHEL doesn't really drop packages, they stay on the CDN for the life of distro. Even if they do get dropped, this seems like an edge case we shouldn't really need to worry too much about. If it happens and it results in an EPEL package not working, we'll know it should have been a Requires and not a Recommends all along, which will lead to either the maintainer adding the necessary dependency to EPEL, or retiring the package with the missing dependency. > > If we don't add HA and RS to the base epel repos, I guess we could just > allow people to build those things they need in epel, but then of course > they get to maintain them. ;( This is already allowed, which is why we have EPEL packages that would need to be retired if HA/RS are added to the target base. > > Perhaps instead of a strict rule we could just ask everything that has > this issue to get an exception? As stated above I'd be fine with an exception workflow if a maintainer feels it's justified to intentionally mislabel a hard dependency as weak, but the general case of truly weak (optional) dependencies from non-target-base channels shouldn't need exceptions IMO. > > Not an easy case. > > kevin > _______________________________________________ > 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 -- 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
