Our existing dash ebuilds pass "--disable-lineno" to the configure script to disable its support for the LINENO variable within scripts. However, LINENO is part of POSIX,
and some scripts expect it to work.
It was disabled in bug #527644 to work around upstream bashisms in some configure scripts. And while I'm sure a few of those problems persist, I make the following arguments:
* As a user, I choose dash for speed. On a Gentoo system, ./configure
scripts are likely the most common place to experience those speedups.
Forcing ./configure to re-exec itself with /bin/bash because it can't
use LINENO is counterproductive to me.
* As a developer, I use dash precisely because I want to find and fix
these upstream bugs. Sweeping them under the rug hurts the upstreams
that care about portability.
* Things are a lot better than they were in 2014 for users of a non-bash
/bin/sh. By now, a lot of the bashisms should have been caught, and
upstreams are at least familiar with the issue (so they won't reject
our bug reports).
There is finally someone working on a new release of autoconf, and this is causing problems:
The LINENO variable is POSIX:
Please, unbreak dash (or let me do it).
I say we give it a try in ~arch. Please go ahead if nobody else protests in the next few day.
Created attachment 619818 [details]
Here's an EAPI=7 ebuild.
Please review: this ebuild also drops the gentoo-only "dumb echo" patch that was enabled by default. You can see in bug 337329 that vapier went on a rant against dash and hacked the shell to work around the fact that imagemagick was using an autoconf macro that was missing a call to AS_ECHO. Those are *precisely* the sort of portability problems that people use dash to detect. Dash's upstream behavior is correct according to POSIX, and this patch was never submitted, so we're doomed to have "echo" act weird on Gentoo forever unless we drop it.
(In reply to Michael Orlitzky from comment #3)
Yeah, I tried disabling the dumb-echo patch by default.
vapier changed the USE flag from "dumb-echo", to "vanilla", which effectively re-enabled the patch by default.
I have no objection to dropping the patch entirely.
The new ebuild looks good to me.
The bug has been closed via the following commit(s):
Author: Michael Orlitzky <firstname.lastname@example.org>
AuthorDate: 2020-03-15 15:34:34 +0000
Commit: Michael Orlitzky <email@example.com>
CommitDate: 2020-03-15 15:56:02 +0000
app-shells/dash: new revision that more-closely matches upstream.
Our dash ebuilds differed from upstream in two ways in the past: we
disabled LINENO support with --disable-lineno, and we patched the
"echo" command to ignore certain arguments and escape sequences.
Disabling LINENO tricks configure scripts into re-executing themselves
with bash, which can hide errors for users (good?), but also hides
them from developers (bad). The LINENO variable is covered by POSIX,
and it's counterintuitive to silently force bash on users who have
explicitly set /bin/sh to dash. This new revision therefore re-enables
LINENO. This same change (in the context of Debian) was discussed on
the autoconf mailing list.
The "dumb echo" patch reflects a similar situation. Dash's upstream
"echo" implementation differs from the bash implementation, but is
correct according to POSIX. This can shed light upon some portability
bugs, particularly in autoconf scripts, and the "dumb echo" patch
hides some of those bugs from end users. But again, it hides them from
the authors as well and thereby perpetuates the portability issues.
Since this patch is Gentoo-specific, and hides problems that are
better addressed elsewhere, this new revision eliminates it.
Package-Manager: Portage-2.3.84, Repoman-2.3.20
Signed-off-by: Michael Orlitzky <firstname.lastname@example.org>
app-shells/dash/dash-0.5.10.2-r1.ebuild | 53 +++++++++++++++++++++++++++++++++
1 file changed, 53 insertions(+)