Simon McVittie <s...@debian.org> 於 2018年12月12日 週三 上午4:22寫道： > > Control: tags -1 + moreinfo > > On Wed, 12 Dec 2018 at 00:45:34 +0800, You-Sheng Yang wrote: > > Somehow dash failed to expand /usr/share/docutils/scripts/python3/*, so > > that exec variable is simply '/usr/share/docutils/scripts/python3/*', > > which is later expanded as extra dozens of update-alternatives' > > arguments. To be more detailed, at the time executed, dash path > > expansion still worked as it's able to expand /usr/share/* and > > /usr/share/docutils*, but it failed to expand /usr/share/docutils/* and > > any other pattern with a /usr/share/docutils/ prefix. Files has been > > installed correctly and accessible, but dash simply unable to expand > > such globs. > > The obvious question is: why don't basic operations like glob() work > on the system in question? > > Is there something unusual on the system where these expansions failed, > like a non-standard filesystem or kernel, or weird permissions > (directories not 0755 or files not 0755 or 0644) anywhere under > /usr/share/docutils?
They have been correctly installed. Only expanding /usr/share/docutils/* and any other expanding attempt with a /usr/share/docutils/ prefix failed. Actually many other directories under /usr/share has the same problem in dash. Not just /usr/share/docutils. > You mentioned Docker containers. What is the host system and how are > these Docker containers configured? If /usr is an overlayfs or similar, > failing to evaluate a glob might be a bug in the overlay implementation? I was running docker images from docker.io/vicamo/debian:sid-<arch> on the same host, so the same host configuration applies to all available Debian Sid images. Other paths have the same issue, with or without python3-docutils installed. I think the root cause should be in dash, but since ptrace is not available inside a qemu-based foreign arch container, it would probably take some time to hunt for the root cause. > (Since 32-bit ARM and MIPS are not exactly fast machines, I would > suggest building your kernels with dpkg-buildpackage -B and using an > x86_64 machine to build documentation, which would maybe sidestep this > by not needing docutils at all.) Just like you, I don't like work-arounds, either. Anyway, the problem is python3-docutils fails to install on container based Sid armel/armhf/mips/mipsel environments. I don't own a real arm32/MIPS board, so I cannot verify if this also happens outside a qemu jail. But while many debian installations today are actually container images, I'd still say this is critical enough that I would recommend a quick fix to unblock all other people while the issue being investigated. > > Replace that path glob with a `find ... -type f` fixes the problem. > > Sorry, I don't think python3-docutils can be expected to swap a path > expansion for a subprocess that ought to be equivalent to work around > whatever is going on with these systems - and definitely not without > understanding what it is that's going wrong and why. > > smcv You-Sheng Yang
