[Pkg-electronics-devel] Bug#1103543: Collision of return codes by GHDL backend switching script

[Paebbels]

In my opinion, it's unlikely that normal users switch versions very often.
Many users will only install a single backend variant of GHDL.

Only a few user roles will switch them. One role is the GHDL enthusiast,
but he will eitherways compile GHDL from sources and install multiple
versions in parallel. The other role is regression testing, but this is
usually
involving CI servers and Docker images for clean separation and cleanup.

I would prefer the reduced startup overhead to achieve good performance.

If this can't be decided, can the deb-file ask what to do? Like script based
switching or using alternatives? Also, this is only relevant when a second
GHDL variant gets installed. Not sure if deb files can handle this scenario
and check.

For the exit code:
I suggest moving it into the reserved range of Bash so 128 .. 255. Maybe a
250.

Kind regards
    Patrick

Am Fr., 17. Apr. 2026 um 21:49 Uhr schrieb Petter Reinholdtsen <
pere at hungry.com>:

> [Paebbels 2026-04-18]
> > Why don't you use alternatives to switch between variants?
> > Wasn't it created exactly for that usecase?
> >
> > Is there really an overwhelming usecase of constantly switching GHDL
> > backende and even operating multiple backends in parallel (for regular
> > users), which justifies such a performance penalty?
>
> Note, I am just a drive by debian developer interested in GHDL, so do
> not take my comments as gospel.  I thus can not explain what the
> author of the wrapper script thought at the time, but I can look at
> the git history of the script (git log -- debian/ghdl.wrapper):
>
> commit f43ae0f8a56c012a7da57fc8c7408f58de7c26e1
> Author: Nicolas Boulenguez <nicolas at debian.org>
> Date:   Wed Dec 14 13:48:00 2022 +0100
>
>     Install the usr/bin/ghdl wrapper with dh_install directly
>
> commit d42537bf8a64365a874446e8772fd74bf094c90f
> Author: Andreas Bombe <aeb at debian.org>
> Date:   Wed Jul 24 18:10:20 2024 +0900
>
>     Revert back to debian/3.0.0+dfsg2-1
>
>     Restore a clean state as reverting individual commits in the series
>     creates massive conflicts that would take too long to resolve.
>
> commit 201a83a5188db826793604066f7b3461128b3899
> Author: Nicolas Boulenguez <nicolas at debian.org>
> Date:   Wed Dec 14 13:48:00 2022 +0100
>
>     Install the usr/bin/ghdl wrapper with dh_install directly
>
> commit e8833d4e1ef4688eda68322d889e6acf3d244712
> Author: Jonathan McDowell <noodles at earth.li>
> Date:   Mon Apr 6 11:30:06 2020 +0100
>
>     Update wrapper for newer releases. Thanks to Pavel Pisa (Closes:
> #930890)
>
> commit 895f335df5736ea1714b576f1811831cfd045116
> Author: Andreas Bombe <aeb at debian.org>
> Date:   Sat Aug 4 00:56:39 2018 +0800
>
>     Change error message in ghdl wrapper
>
>     Make the error message in case no ghdl executable is found less
>     ambiguous and confusing.
>
> commit 6d3a3dfe2af4d94162f0c921611b16832b8fdde2
> Author: Andreas Bombe <aeb at debian.org>
> Date:   Sun Jan 14 20:53:34 2018 +0100
>
>     New Debianization of ghdl
>
> The referred <URL: https://bugs.debian.org/930890 > is a confusing
> read, but apparently the wrapper script interact with the build in
> interesting ways too.  The commits do not explain why the alternative
> system was not used, or if it was considered.
>
> I'm not quite sure what to make of this, but suspect the decisions
> were made by people no longer active with ghdl, and thus no-one around
> can answer your questions.  I do not know ghdl enough to know how
> often it make sense to be able for a user to change backend.  Using
> the alternative system would place the decision in the hands of those
> with root access, while using the environment variable allow each
> non-root user to decide for themselves which backend to use.  I guess
> that might make sense i an multiuser setup.  Apparently the script has
> been around for eight years now.
>
> As the concrete issue reported in this issue seem to be the 'exit 2'
> part of the script, and you seem to know something about exit codes
> from ghdl, can you perhaps propose a better exit code to use in this
> wrapper script?
>
> --
> Happy hacking
> Petter Reinholdtsen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-electronics-devel/attachments/20260417/4ba6af8c/attachment-0004.htm>