Comment 3 for bug 2028571

jdupes normally considers hardlinks as one.

And, indeed, on my Debian system, I see:

-rwxr-xr-x 1 root root 36656 May 27 2021 gunzip*
-rwxr-xr-x 1 root root 36656 May 27 2021 gzip*

These aren’t hardlinks.

And indeed they aren’t hardlinks in the Debian binary package either:

$ paxtar -xOf klibc-utils_2.0.8-6.1_amd64.deb data.tar.xz | xz -d | paxtar -tvf - | fgrep zip
-rwxr-xr-x 1 root root 36656 May 27 2021 ./usr/lib/klibc/bin/gunzip
-rwxr-xr-x 1 root root 36656 May 27 2021 ./usr/lib/klibc/bin/gzip

debian/klibc-utils.install just has:

usr/lib/klibc/bin/*

These get placed there by:

override_dh_auto_install:
        $(MAKE) install $(KLIBC_MAKEFLAGS)

Upstream usr/gzip/Kbuild does hardlink them in the build directory:

$(obj)/gunzip $(obj)/zcat: $(obj)/gzip
        $(call cmd,ln)

The upstream “make install” call causes execution of:

  install -m 755 usr/gzip/gzip usr/gzip/gunzip usr/gzip/zcat ../tmp/usr/lib/klibc/bin

And, indeed, this breaks up the hardlink.

I see two actions arising from this:

① The Debian packaging probably should run something like…

for pkgtopdir in debian/*/; do jdupes -rL "$pkgtopdir"; done

… after installing all the files.

@maximilian attems, are you reading?

② Upstream should probably not use install(1) to install hardlinked files; perhaps recreate the hardlinks in the destination like the BSDs do?

I’ll forward this to the upstream mailing list.