On Mon, 19 Aug 2024 19:21:20 +0200 Sebastian Ramacher <sramac...@debian.org>
wrote:
> On 2024-08-19 12:29:24 +0200, Marco d'Itri wrote:
> > On Aug 19, Sebastian Ramacher <sramac...@debian.org> wrote:
> >
> > > Reserve dependencies failing with unresolved symbols is a sign that
> > > libkmod is missing a SONAME bump. Why hasn't that been done?
> > To make a long story short, upstream did not believe that anything
> > actually used the symbol, and I do not want to have a critical library
> > diverge from upstream.
>
> Then an option is to revert to the previous version or to reintroduce
> the symbol until upstream performs a SONAME bump. Rebuilding the
> reverse dependencies is just papering over the issue.
I believe that the upstream SONAME bump will never happen. Let me add some
details to the story. The symbol kmod_module_get_weakdeps was introduced
in commit 05828b4a6e93 ("libkmod: add weak dependecies"), after v32 had been
released, where the added symbols were mistakenly listed in the LIBKMOD_5
version section. Later, commit 7d72b2238578 ("libkmod: move new weak API to
separate section") fixed this, by moving the symbols to the version
LIBKMOD_30, before the release of v33. As a result, from the upstream's
point of view, both v32 and v33 are good enough.
The issue happened in Debian because the maintainer uploaded a snapshot
version 32+20240327-1, between the above two changes, leaking the new
symbols into the LIBKMOD_5 section.
I think the simplest and cleanest way to solve this is following the kmod
upstream, and rebuilding the affected packages. I searched for broken packages
and found no package refers kmod_config_get_weakdeps@LIBKMOD_5 and only
dracut-install refers kmod_module_get_weakdeps@LIBKMOD_5. So only rebuilding
dracut will solve our problem.
Cheers,
Miao Wang
>
> Closing.
>
> Cheers
> --
> Sebastian Ramacher
>
>
