Bug#1151974: med-fichier: FTBFS: E: dh_python3 fs:172: Not everything in 'debian/python3-med/usr/lib/python3.15/site-packages/med' was able to be merged into 'debian/python3-med/usr/lib/python3/dist-packages/med'.

[Santiago Vila]

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.