Hi folks,
i pushed the updated libfmt v6 to EPEL7 as a fix of [1]. it upgraded libfmt v3.01 to libfmt 6.2.1, and introduced a soname bump for libfmt.so. so packages depending on libfmt should be rebuilt to pick up the new library.
sorry for violating the related policy[2] and the regression[3]. should have sent the mail before pushing the incompatible update to EPEL7. =(
--- [1] https://bugzilla.redhat.com/show_bug.cgi?id=1931239 [2] https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy [3] https://bugzilla.redhat.com/show_bug.cgi?id=1931239
-- Regards Kefu Chai
Am 11.05.21 um 06:45 schrieb kefu chai:
i pushed the updated libfmt v6 to EPEL7 as a fix of [1]. it upgraded libfmt v3.01 to libfmt 6.2.1, and introduced a soname bump for libfmt.so. so packages depending on libfmt should be rebuilt to pick up the new library.
It would be helpful if you could also list the affected packages (repoquery).
Felix
On 11.05.21 06:45, kefu chai wrote:
Hi folks,
i pushed the updated libfmt v6 to EPEL7 as a fix of [1]. it upgraded libfmt v3.01 to libfmt 6.2.1, and introduced a soname bump for libfmt.so. so packages depending on libfmt should be rebuilt to pick up the new library.
While reading this I noticed that the recent fluidsynth-libs update also introduced a soname bump. Affected EPEL packages - audacious-plugins-amidi - qsynth
-- Leon
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
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?
CentOS Stream suffered from that but covered yet:
https://lists.centos.org/pipermail/centos-devel/2021-May/076839.html
Would it not be beneficially? Especially for such cases like these ...
-- Leon
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
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
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.
kevin
On Tue, May 11, 2021 at 2:02 PM Kevin Fenzi kevin@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
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
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.
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. 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.
Troy
On 11.05.21 23:44, Troy Dawson wrote:
On Tue, May 11, 2021 at 2:02 PM Kevin Fenzi <kevin@scrye.com mailto:kevin@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...
[2] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject...
[3] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject...
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...
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...
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject...
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...
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
On Wed, May 12, 2021 at 12:44:09PM +0200, Leon Fauster wrote: ...snip...
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...
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)
Yeah, that should be possible.
As Kevin said, the whole situation could be revised. I'd appreciate hearing your suggestions.
You can of course always download the previous versions from koji and downgrade locally.
You can also use the yum-local plugin to keep local copies of every package you update around to download later.
There are probibly other ways too.
kevin
epel-devel@lists.fedoraproject.org
-
Christoph Karl -
Felix Schwarz -
kefu chai -
Kevin Fenzi -
Leon Fauster -
Troy Dawson