(Sorry, this seems to have gotten stuck in the drafts folder)
Hello Felipe,
thanks for the hint.
Zitat von Felipe Sateler <fsateler@debian.org>:
> I think the more relevant question is whether version 2.0.0 introduced any
> backwards-incompatible change.
According to the documentation, version 2.0.0 introduced incompatible
API changes, not only adding new functions.
Bummer. Hopefully the API changes don't impact everyone.
> If so, then it probably needs fixing in all
> reverse dependencies before it can be updated.
For the binary library this can probably be handled by installing both
libfluidsynth1 and libfluidsynth2 packages.
Right.
Is there a way to handle incompatible and conflicting
libfluidsynth-dev versions?
For example source package A build-depends on libfluidsynth-dev
<2.0.0, source package B and build-depends on libfluidsynth-dev >=
2.0.0?
Until now I didn't find information about this topic. Links to related
documentation are welcome.
But does it make any sense to keep both versions? Does fluidsynth upstream plan to continue supporting both?
Or does this mean that all packages that build-depend on
libfluidsynth-dev would have to be changed to use version >= 2.0.0?
I think this is the more viable option. The number of packages is not large (I see 24), and many are maintained here in this team.
I think the first step would be to prepare a package targeting experimental, see how much stuff fails to build and how hard it is to fix. With that info, it can be decided if it's best to keep both or port all apps to version 2.0.
--
Saludos,
Felipe Sateler