fixing a bug in stable or backporting from testing?

[Michael Tokarev <mjt@tls.msk.ru>]

Hi!

I'm facing an interesting tidbit here. New qemu (5.1) uses
symbols from libfdt (which comes from device-tree-compiler
source package). In libfdt there were a bug, - upstream
forgot to mark some symbols for export, there's a bug about
this -- #931046, the change is to add 3 (iirc) lines to
the corresponding symbols file.

New qemu uses one of these missing symbols, so it can't be
compiled on buster, - it needs fixed libfdt.  In unstable
libfdt is fixed, but it has a new major version, and the
version in buster is sufficient for qemu, except of that
very single symbol which it uses.

Now the question is what to do here. I can backport whole
device-tree-compiler package from current testing to
buster, or we can somehow fix this issue on buster
without a backport, - technically we don't need the
backport at all, we only need to fix this simple bug
in stable.  But the thing is that I don't see an
interest of fixing this issue on buster from the
package maintainers, and that way we'll have to
wait for the next point release anyway.

An alternative will be to make a "fixed backport"
of device-tree-compiler, - take the version from
buster, fix this bug, and call it bpo10-1.

And one more alternative, which is ugly, is to use
libfdt which comes together with qemu sources
(qemu embeds many not-so-common software within
its source tarball just to make compiling it in
various environments easier, and this might be
the case where we can use this easy way, but it
definitely is against debian way).

What's the good way to deal with this?

Thanks,

/mjt