Re: Handling packages with missing dependencies provided by HA-RS repos?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Fedora Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Announce]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux