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.