[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: nlohmann-json3-dev need to be reverted to trixie version



On Mon, Sep 15, 2025 at 08:23:50PM +0000, Gianfranco Costamagna wrote:
> 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.

Yes this would be a Debian specific ABI. This would be annoying.

> 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?

If you change nlohmann-json3 ABI, you change libxeus11 ABI, so you need a new
soname for libxeus11 (say libxeus11-nlohmann-json3.12.0) so a Debian-specific
ABI, and according to Debian convention, a new package name
libxeus11-nlohmann-json3.12.0.  Having a package name change due to a binNMU is
not realistic.

And not just for libeus but for all other libraries affected.

> At the end we are speaking about forcing reverse-dependencies to pick up the right version, and make sure it is used or rebuilt

This is not possible. You cannot change the ABI in a binNMU.
The only solution is to use a different source and binary package name for
every nlohmann-json3 versions, as I explain in the bug report.

> just a question, why is xeus the only affected package?

It is not, it is just that nobody has reported the bug for other libs.
For example libvisp-mbt3.6t64 has the same bug:

stable: libvisp-mbt3.6t64_3.6.0-5_amd64.deb

% nm -D usr/lib/x86_64-linux-gnu/libvisp_mbt.so.3.6.0 | grep nlohmann
                 U _ZN19vpHomogeneousMatrix10parse_jsonERKN8nlohmann16json_abi_v3_11_310basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmdSaNS1_14adl_serializerES4_IhSaIhEEvEE
                 U _ZNK19vpHomogeneousMatrix15convert_to_jsonERN8nlohmann16json_abi_v3_11_310basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmdSaNS1_14adl_serializerES4_IhSaIhEEvEE

so v3_11_3

testing: libvisp-mbt3.6t64_3.6.0-5+b1_amd64.deb

% nm -D usr/lib/x86_64-linux-gnu/libvisp_mbt.so.3.6.0 | grep nlohmann
                 U _ZN19vpHomogeneousMatrix10parse_jsonERKN8nlohmann16json_abi_v3_12_010basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmdSaNS1_14adl_serializerES4_IhSaIhEEvEE
                 U _ZNK19vpHomogeneousMatrix15convert_to_jsonERN8nlohmann16json_abi_v3_12_010basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmdSaNS1_14adl_serializerES4_IhSaIhEEvEE

so v3_12_0

So the binNMU changed the ABI, which is wrong. This will cause a crash when upgrading to forky.

Now really to fix this bug you need to check every library linking with
nlohmann-json and report a bug if they use the wrong ABI.

Once the correct nlohmann-json3 3.11.3 is back in the archive, you can request
a binNMU of the affected packages.

If you want to upload 3.12.0, create new source nlohmann-json3.12.0 and binary
package nlohmann-json3.12.0-dev.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 


Reply to: