Hi josch,

Per our IRC chat, I found tarfilter stuff[0] triggers a regression of old dash bug #606756.

[0] https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/465c0564345b456c41016abc6a4b1cb727125961

I narrowed it down with this test command:

    git bisect start 0.7.1 0.6.1
    git bisect run ./mmdebstrap --quiet --mode=unshare --variant=apt --dpkgopt=path-exclude='/usr/share/man/*' stable /dev/null

...that relies on mmtarfilter being in $PATH, so you will need mmdebstrap 0.7.x package installed.

Attached are some files:

  git-bisect.log - a log of the git bisect
  bad.log        - a log of the actual error (from dpkg.postinst)
  workaround.log - a log of a minimal workaround
  tar-t.log      - a log of showing the final tarball's contents with different commits & options

I think the last one shows a clear difference between tarfilter and dpkg's built-in exclusions.

Note both your original "reinstall essential" strategy, and your newer
tarfilter strategy are THEMSELVES workarounds for THIS bug in dpkg:

https://bugs.debian.org/603700

Hi,

Quoting Trent W. Buck (2020-10-20 16:15:07)

I think I understand the problem now. So, the original problem is, that since I
introduced the tarfilter command, so that packages do not need to be
re-installed when using the dpkg path-excluded option, dash fails to install
with the following error when excluding /usr/share/man/*:

ln: failed to create symbolic link '/usr/share/man/man1/sh.1.gz.tmp': No such file or directory

This makes sense, because indeed the directory /usr/share/man/man1 was excluded
and thus the symbolic link cannot be created. The question is, why did this
work before? The answer is simple: before the tarfilter, the initial package
installation was done with the /usr/share/man/man1 still present, because
before tarfilter, mmdebstrap would just extract the full package contents. Only
the re-install step would then delete everything according to the path-excluded
option. But at that point, the relevant part of the postinst script is not run
anymore, so there will not be a failure.

Also, re-reading #606756 and also the dash postinst, I see nothing that is a
safeguard against a missing /usr/share/man/man1. I think I should open another
bug against dash because it clearly fails to install without
/usr/share/man/man1 present.

Thanks!

cheers, josch

Quoting Johannes Schauer (2020-11-14 00:37:14)

I can confirm that the following patch to dash fixes the problem:

--- a/debian/dash.postinst
+++ b/debian/dash.postinst
@@ -132,8 +132,10 @@ if [ $debconf ]; then
        db_get dash/sh
        if [ "$RET" = true ]; then
                claim_binsh /bin/sh dash
+               if [ -d /usr/share/man/man1/ ]; then
                claim_binsh /usr/share/man/man1/sh.1.gz dash.1.gz \
                        /usr/share/man/man1/sh.distrib.1.gz
+               fi
        else
                unclaim_binsh /bin/sh dash
                unclaim_binsh /usr/share/man/man1/sh.1.gz dash.1.gz \