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?
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?
(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.)
> 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
