On 11.05.21 23:44, Troy Dawson wrote:


On Tue, May 11, 2021 at 2:02 PM Kevin Fenzi <ke...@scrye.com <mailto:ke...@scrye.com>> wrote:

    On Tue, May 11, 2021 at 09:35:40PM +0200, Leon Fauster wrote:
     > On 11.05.21 14:02, Christoph Karl wrote:
     > > Hi!
     > >
     > > On 11.05.21 at 12:30 Leon Fauster wrote:
     > > > While reading this I noticed that the recent fluidsynth-libs
    update
     > > > also introduced a soname bump. Affected EPEL packages
     > > > - audacious-plugins-amidi
     > > > - qsynth
     > >
     > > Yes, this was me. I am already trying to clean up this.
     > >
     >
     >
     > BTW: As also stated here:
     >
     >
    https://lists.centos.org/pipermail/centos-devel/2021-May/076864.html
    <https://lists.centos.org/pipermail/centos-devel/2021-May/076864.html>
     >
     > previous releases (multiple) are not kept but I was assuming that its
     > possible to downgrade at least to ONE version before but it isn't.
     >
     > - Was there ever a downgrade option in EPEL?

    no.

     > CentOS Stream suffered from that but covered yet:
     >
     >
    https://lists.centos.org/pipermail/centos-devel/2021-May/076839.html
    <https://lists.centos.org/pipermail/centos-devel/2021-May/076839.html>
     >
     > Would it not be beneficially? Especially for such cases like
    these ...

    There's a number of reasons we haven't implemented this over the years:
    tooling isn't setup for it easily, desire to not keep publishing
    insecure/broken/vulnerable packages, etc. We could revist it again, but
    it's not something that would change quickly.



To be honest I asked out of curiosity and less to advocate for it,
but lets put that hat on and start a dialetic speech.
(and before that; I love EPEL and I do shout out a big thank
you to all volunteer maintainers + EPEL SIG members!):



Context:

I understand that the toolbox is a beast [1], "highly complex" and also a
"strain on the Fedora volunteers" [2] and "nobody is paid to work on EPEL" [3]

[1] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/HKNX6N3NVL2WCT3FQPNLP3BDSDZFVG2O/

[2] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/3UAANIDFQNIMBOZ4DEHM6KUPUUL3B5MG/

[3] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/KW2UE3U4SPNUJZGFZQLFFDSNO4LEK56S/



CentOS Stream 8 can have major changes, with little warning of those changes.  An example is qt5 was recently updated to qt5-5.15, from 5.12. If they hadn't implemented the backup stuff before that, all new KDE users would be stuck. So, CentOS Stream has very good motivation to make that change to their repo.

EPEL is supposed to be stable.  With things like what happened on this thread, being the exception, instead of the rule.


State:

The intention is to be stable but it isn't and Smooge clearly explains it here:

https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/VGF65WVDAZMNT2FK5EAO3YQ6XJ4HBCEE/

and also a nice illustration that explains the state: "EPEL is more of a
Stone Soup collection of packages branched from Fedora." [3]


It the last 48-hours two soname bumps that cause deps problems (also against rpmfusion):

https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/MF4MAQ4ZKPYNI3JXEMNX5RAZDXVRXNEI/

https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/JP4YUYTLLA4GLUEHXEAJGIFSY6L3TIML/



We do realize that at each RHEL minor release, things can change, and because of that we archive/backup when this happens.  So, in one sense, we do have a backup, just not an active backup.  It's more like a six month snapshot.

Summary:  EPEL and CentOS Stream have different release cadence and policies.


I do not wanted to compare this two and achieving the same functionality
seems to me to be a "giant project" [1] now, but reading your answer
following is coming into my mind: EPEL-next - a set of packages built
against CentOS Stream. So, the same state will spread over to EPEL-next.



Proposals:

"yum downgrade" out of the box seems to be unrealistic. What about the archives:

EPEL snapshots of releases:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/QLYF7M7UU7FFSBQTOIK7MFCAYS6TXDVZ/

People like programmatically ways: How reach the "downgrade" goal
via such archives?

Would a repo config for the archives in epel-release be a viable
solution? (details have been intentionally omitted)


As Kevin said, the whole situation could be revised. I'd appreciate hearing your suggestions.

--
Leon

_______________________________________________
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to