[Python-modules-team] Bug#916225: python3-docutils doesn't install on Sid armel/armhf/mips/mipsel

[vicamo at gmail.com]

Simon McVittie <smcv at 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