mirror of
https://github.com/quamotion/dotnet-packaging.git
synced 2026-02-14 13:45:53 +00:00
Fix native dependency for XZ compression #3
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @qmfrederik on GitHub (Sep 26, 2017).
RPM packages use xz compression for compressing the package payload.
Currently XZ compression is implemented via the XZOutputStream which uses liblzma under the hoods to perform the compression.
This P/Invokes into liblzma. Different Linux distributions may ship different versions of liblizma, so loading the correct version of liblzma may be a bit of a challenge. For example, on RedHad, the so name is
liblzma.so.5.We should either amend the code that loads liblzma to search for different versions of liblzma (possibly depending on the host OS); or replace liblzma by a managed implementation.
@qmfrederik commented on GitHub (Sep 26, 2017):
A cursory search on GitHub and NuGet didn't reveal any fully-managed xz compression implementations (there are some decompressors, though). So we may be stuck with the native dependency for now.
The better option the may be to amend NativeMethods so that it searchers for different versions of liblzma, and possible also set up Travis support for running some tests in a CentOS container to excercise this code.
133ffd8883/Packaging.Targets/IO/NativeMethods.cs (L43-L55)@qmfrederik commented on GitHub (Sep 26, 2017):
/cc @tmds split off from #6
@kekekeks commented on GitHub (Oct 2, 2017):
Have you considered building liblzma with some ancient version of glibc (so library will work across all glibc-based distros) and shipping it inside NuGet package? I can do that, if you want.
@qmfrederik commented on GitHub (Oct 2, 2017):
@kekekeks This would create a "portable" version of
liblzma, pretty much like .NET Core is now portable accross glibc-based distributions, right?That sounds like a good plan, it helps us work around the requirement to have the user install liblzma.
Only requirement I'd have is that the build process is open & reproducible (ideally via travis or a similar service). I can configure Travis to build as part of this repository, if that helps
@kekekeks commented on GitHub (Oct 2, 2017):
Is a
Dockerfilefor creating a builder image OK?@qmfrederik commented on GitHub (Oct 2, 2017):
Absolutely!