On Thu, Mar 24, 2022 at 5:50 PM Kevin Fenzi <kevin(a)scrye.com> 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(a)redhat.com> 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."
> > 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
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
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.
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
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure