On Sun, Oct 25, 2026 at 07:12:11PM +0100, Gilles Filippini wrote: > But how I see it, this is a bug in dh-python which handles removing / > renaming shared libraries from the > 'debian/python3-med/usr/lib/python3.15/site-packages/med/' folder. > > The fact that it doesn't know what to do with symlinks such as > '_medfield.so.0 -> _medfield.so.0.0.0' is not the fault of med-fichier or > the way it is built. > > The med-fichier build was fine before the upload of dh-python 7.20261019. > > What do you think?
Lots of things break all the time (think about switching from gcc-14 to gcc-15, for example), and it does not mean they were "correct" before, it just means that the new tools are more strict in what they accept. In this case, I would try adding `-avoid-version` to `_*_la_LDFLAGS` and see if the problem disappears. (Sorry, I'm not an expert on these low level things, if you are still in doubt, I guess you could try filing a normal bug against dh-python and most probably the author will explain why this happens). BTW: This is what my AI assistant tells me, but of course the usual caveats apply: The `.so.0` -> `.so.0.0.0` symlinks aren't a supported Python layout — they're libtool artefacts from linking the wrappers with `-module` but *without* `-avoid-version` (`python/Makefile.am` even still has the line `# _medlibrary_la_LDFLAGS = -avoid-version -module` commented out). Python only ever imports the unversioned `_medfield.so`; nothing in Python or dh-python promises to preserve versioned extension modules. So dh-python 7.20261019 didn't break a correct install, it exposed a fragile one. Thanks.
