pkgs/test/buildFHSEnv/default.nix
83:      (getSharedObjectFromDebian "libxml2.so.2.9.14" (fetchurl {

pkgs/applications/editors/vscode/extensions/ms-dotnettools.csdevkit/default.nix
45:    (lib.getLib libxml2) # libxml2.so.2

pkgs/development/libraries/gobject-introspection/absolute_shlib_path.patch
161:+            libxml2.so.2 => @nixStoreDir@/72mxkk74cv266snkjpz1kwl1i2rg8rpc-libxml2-2.9.8/lib/libxml2.so.2 (0x00007f0ee119c000)

quick search for breaking change
How can we solve this?

https://gitlab.gnome.org/GNOME/libxml2/-/issues/889
https://gitlab.gnome.org/GNOME/libxml2/-/issues/890

Please consider updating this to 2.14.2.

In the meantime, i opened #399595 so we are not suck on a vulnerable version. The 2.13.8 update is non-breaking. I am happy to get 2.14.x versions, but didn't feel confident pushing that yet.

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 396195 --package libxslt --package docbook2x --package python3Packages.lxml --package clang --package libarchive --package libxml2

x86_64-linux

pkgs/test/buildFHSEnv/default.nix
83:      (getSharedObjectFromDebian "libxml2.so.2.9.14" (fetchurl {

This is refering to a Debian package, no need to do anything.

pkgs/applications/editors/vscode/extensions/ms-dotnettools.csdevkit/default.nix
45:    (lib.getLib libxml2) # libxml2.so.2

If I comment out the line, vscode-extensions.ms-dotnettools.csdevkit will fail to build so it probably will not work with the new version:

auto-patchelf: 1 dependencies could not be satisfied
error: auto-patchelf could not satisfy dependency libxml2.so.2 wanted by /nix/store/vjbxkh0xs0vmwmay3flqdhrfjh8zcsx8-vscode-extension-ms-dotnettools-csdevkit-1.18.25/share/vscode/extensions/ms-dotnettools.csdevkit/components/vs-code-coverage/platforms/linux-x64/node_modules/@microsoft/coverage-services.linux-x64/ubuntu/x64/libInstrumentationEngine.so

The comment should be updated and vscode-extensions.ms-dotnettools.csdevkit needs to be bumped (if there is a newer version compatible with libxml2.so.16), or marked as broken. cc @GGG-KILLER

pkgs/development/libraries/gobject-introspection/absolute_shlib_path.patch
161:+            libxml2.so.2 => @nixStoreDir@/72mxkk74cv266snkjpz1kwl1i2rg8rpc-libxml2-2.9.8/lib/libxml2.so.2 (0x00007f0ee119c000)

This is just a test, no need to change it.

The comment should be updated and vscode-extensions.ms-dotnettools.csdevkit needs to be bumped (if there is a newer version compatible with libxml2.so.16), or marked as broken. cc @GGG-KILLER

If possible I'd prefer that the previous libxml version is kept, as this is a very critical extension for all .NET developers in NixOS and the impact of marking it as broken would be huge.

There is no new version afaik since @r-ryantm has already updated the package to the latest version.

That is unfortunately not feasible since security vulnerabilities are regularly discovered in libxml2. So even if we kept an older version, it would be shortly marked as insecure.

Do you think upstream would be willing to update to a newer version?

That is unfortunately not feasible since security vulnerabilities are regularly discovered in libxml2. So even if we kept an older version, it would be shortly marked as insecure.

I see, that's very unfortunate indeed. Guess there's no choice.

Do you think upstream would be willing to update to a newer version?

I'll open an issue in their repo referencing this PR, but in the meantime, I think I'll let autoPatchelf ignore that dependency and have this specific feature be broken, since it seems to be only related to code coverage and not other more critical features.

That is unfortunately not feasible since security vulnerabilities are regularly discovered in libxml2. So even if we kept an older version, it would be shortly marked as insecure.

Do you think upstream would be willing to update to a newer version?

I guess the vulnerability was fixed at 2.13.8.

edit: I didn't see 'regularly', sorry.

Reading https://gitlab.gnome.org/GNOME/libxml2/-/issues/751, it might be the case that the ABI breakage is not relevant, so we could create a hack like:

(runCommand "libxml2-fake-old-abi" {} ''
  mkdir -p "$out/lib"
  ln -s "${lib.getLib libxml2}/lib/libxml2.so" "$out/lib/libxml2.so.2"
'')

Not sure if it that will work, might be worth a try.

I won't be able to do anything about this until next week, but if that solution works (builds, no need to actually check if the extension itself works) then I'm okay with it being added to this PR or in another PR if you prefer.

Broke ldc: #414928

Regression in binaryninja-free (#418655) and ciscoPacketTracer8 (#418660)

They bumped soname, so most things using our libxml2 that aren't built from source by us will have issues. We might consider adding older libxml2 for these cases, though it might become rather complicated to juggle the versions.

EDIT: the references above are very often the same – patchelf attempt with libxml2.so.2

Regression in unityhub (#419634)

Yea, i agree on keeping the older version (as a separate package, e.g. libxml2_2 for compat reasons.

See above

Reading gitlab.gnome.org/GNOME/libxml2/-/issues/751, it might be the case that the ABI breakage is not relevant, so we could create a hack like:

(runCommand "libxml2-fake-old-abi" {} ''
  mkdir -p "$out/lib"
  ln -s "${lib.getLib libxml2}/lib/libxml2.so" "$out/lib/libxml2.so.2"
'')

Not sure if it that will work, might be worth a try.

Maybe we can implement this instead of keeping the old version.

I'd say that's asking for unpleasant surprises during runtime.

For what it's worth, Arch did create a libxml2-legacy for these binary packages that can't be recompiled for the new ABI (see link)

It looks like we might be able to build libxml2 with --with-legacy to significantly reduce the ABI breakage. We could consider doing that in libxml2 itself and adding the symlink hack. Or we could introduce a new "legacy" package that does it to protect most users from the edge cases.

We already did. It's libxml2_13.