On 21-09-2022 11:35, Ricardo Wurmus wrote: > * gnu/packages/crates-io.scm (rust-libz-sys-1)[source]: Only delete bundled > zlib sources. > --- > gnu/packages/crates-io.scm | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/gnu/packages/crates-io.scm b/gnu/packages/crates-io.scm > index 42a44a2930..f7703f9295 100644 > --- a/gnu/packages/crates-io.scm > +++ b/gnu/packages/crates-io.scm > @@ -32568,9 +32568,9 @@ (define-public rust-libz-sys-1 > "1q25cb8vs113si7q2p0innhi8jk0wpq37hqi2wcc219hcmw43cr3")) > (modules '((guix build utils))) > (snippet > - '(begin (delete-file-recursively "src/zlib") > - (delete-file-recursively "src/zlib-ng") > - #t)))) > + ;; Do not delete zlib-ng, because we have no native library > + ;; for it. > + '(delete-file-recursively "src/zlib")))) According to the README, zlib and zlib-ng are supposed to be compatible, so zlib-ng should be removable (as long as dependents don't enable zlib-ng, but that can be patched out). Additionally, using zlib-ng can cause problems if the application also links to the regular zlib: README.md ‘and as long as you don't also dynamically pull in a copy of stock zlib (which will produce conflicting symbols)’ Proposal: keep removing zlib-ng, and modify the enabled features in whatever crate or Rust application asks for zlib-ng. Greetings, Maxime.