Hi,
This is entirely my fault, and I apologize. Will respond inline and discuss potential workarounds below. Also cc:ing epel-devel which is relevant.
On Thu, Nov 17, 2022 at 02:18:48PM +0100, Fabio Valentini wrote:
On Thu, Nov 17, 2022 at 1:33 PM Bob Mauchin zebob.m@gmail.com wrote:
On Thu, 17 Nov 2022, 10:09 Remi Collet, Fedora@famillecollet.com wrote:
** Please, manage EPEL-9 like a "stable" branch. **
soname change should be avoid, if not possible (security exception ?) should be properly managed and, at least, announced
That is indeed the policy: https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
and I should have posted an announcement before putting up an update.
Those are my packages but I don't recall authoring such changes? I remember considering David 1.0.0 for EPEL9 but didn't do so because of the dependency nightmare.
I assume the dav1d 1.0.0 update was accidentally merged from Fedora when building dependencies for rav1e. I've pinged salimma on IRC / Matrix about this, he pushed these changes.
Indeed. When bringing up rust-rav1e, I did not notice the strict version dependency between rust-dav1d and dav1d until most of the rest have been built.
This is the first mistake, had that been caught earlier I would have tried building an older version of rust-dav1d and other crates depending on it.
In EPEL itself only libavif uses it, which is in turn is only used by kf5-kimageformats, which has a planned update going out soon, so between just rebuilding libavif or also rebasing it, it seems to be a good time to also update it: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-385df27ee1
Now this brings up two questions; I'll start with the more immediate one.
## Since dav1d update is already out though, what's the best path forward?
- I can package a dav1d092 compatibility package to provide libdav1d.so.5 - I can also package a compatibility libavif package, but against which dav1d? - rebuild rpmfusion dependents against dav1d 1.0 and libavif 0.11
## How do we better address (Fedora, EPEL) <=> RPM Fusion dependencies?
On the Fedora side there is nothing currently that officially considers RPM Fusion (beyond the few allowlisted subsets like the Nvidia drivers). Amending the incompatible update policy to mention RPM Fusion is probably a no-go, but maybe mentioning "consider testing against well-known and popular third party repos" is doable?
Best regards,
Le jeu. 17 nov. 2022 à 15:45, Michel Alexandre Salim salimma@fedoraproject.org a écrit :
- I can package a dav1d092 compatibility package to provide libdav1d.so.5
- I can also package a compatibility libavif package, but against which dav1d?
- rebuild rpmfusion dependents against dav1d 1.0 and libavif 0.11
As RPM Fusion is concerned, the rebuild is done and is scheduled on the next push. (currently occurring).
## How do we better address (Fedora, EPEL) <=> RPM Fusion dependencies?
On the Fedora side there is nothing currently that officially considers RPM Fusion (beyond the few allowlisted subsets like the Nvidia drivers). Amending the incompatible update policy to mention RPM Fusion is probably a no-go, but maybe mentioning "consider testing against well-known and popular third party repos" is doable?
While there might be a fedora project wide policy not to assume any 3rd party complement (but still the official documentation mentions the project explicitly these days, with a dedicated notice). I would still expect an appropriate communication level to be held at the individual package maintainers level. Not more, not less than any friendly communication that is expected to be held to any external projects from Fedora.
Now of course one can't expect to contact any single maintained project at scale (like copr projects or else), but there I draw the difference between a single maintained project and a well known community based one.
Thanks for raising this point. I hope this problem will be behind us soon.
epel-devel@lists.fedoraproject.org
-
Michel Alexandre Salim -
Nicolas Chauvet