Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#842242: dash: Missing $LINENO support avoids using dash for autotools ./configure scripts

21 views
Skip to first unread message

Tim Ruehsen

unread,
Oct 27, 2016, 7:00:03 AM10/27/16
to
Package: dash
Version: 0.5.8-2.3
Severity: normal

Dear Maintainer,

autotools configure scripts always fall back to bash due to switched-off $LINENO
support. This makes running ./configure scripts much slower in comparison to
using dash.

I am aware of #766048, but the provided link is no longer available and thus it
is not possible to see why the build failed.
Maybe these 'several packages' needs to be fixed.

As developer who uses ./configure all day long, I am suffering from not being able to
use dash. AFAIK, other distros do not use --disable-lineno for packaging.

Regards, Tim

-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dash depends on:
ii debianutils 4.8
ii dpkg 1.18.10
ii libc6 2.24-5

dash recommends no packages.

dash suggests no packages.

-- debconf information:
* dash/sh: true

Benjamin Cama

unread,
Jan 24, 2018, 5:10:04 AM1/24/18
to
Hi,

I wondered too about the problem highlighted in #766048 pointed by this
bug, and did not understand why $LINENO support was kept disabled. I
found an answer in #582952 which is, from what I understand, similar to
#766048:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582952

So, keeping $LINENO support disable is *intentional* so as configure
*does not* catch dash as the default shell, because it breaks a lot of
packages with bashisms. The bug highlights the reason of this
deactivation, even if “long term” solution is to fix all the bashisms.
So, as long as we have bashisms, we must have slow configure for
everyone…

So maybe this bug could be merged/closed?

--
Benjamin Cama - Tél : 258

Tim Rühsen

unread,
Apr 5, 2018, 11:20:03 AM4/5/18
to
> So, keeping $LINENO support disable is *intentional* so as configure
> *does not* catch dash as the default shell, because it breaks a lot of
> packages with bashisms. The bug highlights the reason of this
> deactivation, even if “long term” solution is to fix all the bashisms.
> So, as long as we have bashisms, we must have slow configure for
> everyone…

Yeah, sounds like that.

For the interested, I wrote some hints on how to dramatically speed up
configure scripts:
https://gitlab.com/gnuwget/wget2/wikis/Developer-hints:-Increasing-speed-of-GNU-toolchain

A list of broken packages due to bashisms would also be very helpful to
create patches for upstream (count me in).

Another long-term solution would be a 'bash mode' for autoconf, to create a
bash-only configure script with all the possible speedups that bash offers.

(Just an idea.)

> So maybe this bug could be merged/closed?

For me it's currently a WONTFIX, so not against closing it.

Regards, Tim


signature.asc

Andrej Shadura

unread,
Nov 2, 2021, 7:40:04 AM11/2/21
to
Control: tag -1 pending

On Thu, 27 Oct 2016 12:49:38 +0200 Tim Ruehsen <tim.r...@gmx.de> wrote:
> Dear Maintainer,
>
> autotools configure scripts always fall back to bash due to switched-off $LINENO
> support. This makes running ./configure scripts much slower in comparison to
> using dash.
>
> I am aware of #766048, but the provided link is no longer available and thus it
> is not possible to see why the build failed.
> Maybe these 'several packages' needs to be fixed.
>
> As developer who uses ./configure all day long, I am suffering from not being able to
> use dash. AFAIK, other distros do not use --disable-lineno for packaging.

Indeed, having read the history of the bug (see #582952), it seems it’s
probably now worth trying to re-enable it again.

--
Cheers,
Andrej
0 new messages