Re: nlohmann-json3-dev need to be reverted to trixie version
Hello,
>I do not see much alternative.
I still would like to quickly have a strong solution to this instead of reverting to old version
>We tried to explain this four times already. If you were unsure, you could
>have discussed your plan in the bug report #1106511 in advance, and please
>remember to always CC the submitter when posting to a bug, otherwise the
>submitter does not get a copy, only the maintainer.
I got a ton of bug reports, tried to find the discussion, and I still didn't manage to find it, 1106511 doesn't contain the information
my brain is sure to have read some time ago, but don't remember where
>libxeus11 is a shared library and so has a _fixed_ ABI that _cannot_ be changed.
>However its ABI incorporates nlohmann-json3 ABI so it needs to be build always with the same nlohmann-json3 ABI.
>However nlohmann-json3 upstream has set up nlohmann-json3 so that its ABI include the version number, so
>that means that libxeus11 must always be built with the exact same version of nlohmann-json3, which is 3.11.3.
>When libxeus12 is released, it will incorporate a newer nlohmann-json3 version, and so we will be able to move to
>that new version, but not before.
>
>Rebuilding libxeus11 with 3.12.0 with lead to a libxeus11 package with a wrong ABI.
I presume having libxeus11a/b/c is a no-go, I don't want to discuss because looks wrong to me too.
I still would like to know if we can fix by having some shlibs bump like libfilezilla did some years ago, forcing rebuilds,
or to have libxeuss11 implement some abi Provide in the same way nlohmann-json3 is now doing. Would it be feasible?
At the end we are speaking about forcing reverse-dependencies to pick up the right version, and make sure it is used or rebuilt.
>so the library is incompatible.
>
>This is the issue that happened last time with 3.11.2->3.11.3, see #1060164.
just a question, why is xeus the only affected package? I guess none of the other packages are exposing such abi in their library?
Maybe they don't use json directly in their public library?
>From what I can see, it was worked around in a way that my nlohmann-json3-abi-3.12.0 would solve semi-automatically...
>This issue was worked around because libxeus9 was going to be replaced by libxeus10.
>But so far I see no plan for a libxeus12, so we cannot afford to break libxeus11.
worked around for xeus, but still:
1) is the only breakage we know, or was it fixed with soname bump leaving other packages affected? This would be even worse
2)
>And of course there are other libraries using nlohmann-json3 that might have the same issue.
yeah, I fully agree
>Debian takes library ABI seriously.
So I do
Please let use this bug to make sure we can find a better approach to this report, even if this means renaming nlohmann-json3 at each new release.
G.
Reply to: