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(a)gmail.com>
wrote:
>
>
>
> On Thu, 17 Nov 2022, 10:09 Remi Collet, <Fedora(a)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,
--
Michel Alexandre Salim
identities:
https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2