Re: Does EPEL 9 maintain upgrade path from EPEL 8?

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

 





On Sat, 19 Feb 2022 at 15:55, Neal Gompa <ngompa13@xxxxxxxxx> wrote:
On Sat, Feb 19, 2022 at 3:21 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
>
> Hello,
>
> I have a Fedora package that I've recently also branched for EPEL 9.
>
> The (so called) binary package used to be called "python3-tox", but has been
> renamed to "tox" in Fedora 34. All supported Fedora versions and EPEL 9 have
> the package named as "tox". The package has:
>
>      %py_provides    python3-tox
>      # Remove this once Fedora 36 goes EOL:
>      Obsoletes:      python3-tox < 3.24.4-2
>
> However, the EPEL 8 package is still called python3-tox.
>
> Once I remove the Obsoletes line from Fedora, should I worry about merging that
> commit to the epel9 branch or not? Logic dictates that the Obsolete should
> remain in EPEL 9 forever, but I wonder if there is a policy/rule of thumb. E.g.
> in Fedora, we only support upgrades to Fedora N+2. Do we support upgrades of
> EL+EPEL systems as well and how "far"?
>

Ideally, we support EL X-1 -> EL X. So EPEL9 *should* upgrade EPEL8
packages, but I don't know if we enforce this.


We have NEVER enforced this before because EL X-1 -> EL X was only supported under a tight contract for RHEL with special consultant support (aka you were probably going to just reinstall anyway). For EL7 to EL8, it sort of works on the EL side but most side repositories don't mainly because you are jumping from the packaging formats of Fedora 18 to Fedora 29. For EL8 to EL9 it is more manageable since it is from Fedora 29 to Fedora 34. That said there are a LOT of side effects which aren't really even tested from Fedora N to Fedora N+1 at the level that most people use an 'Enterprise' OS versus a 'Hobby' OS. [Those are mostly unfair characteristics but what most consumers of EL vs Fedora use in their heads.]

Honestly, if someone pays someone a lot of money to pay for engineers to do this and yes it could be supported. Otherwise we have to use the copious (aka non-existant) time from Neal and others to somehow make it happen because 'it should happen'



--
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren
_______________________________________________
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