Hi, 在 2022-05-01星期日的 23:35 +0200，Gunnar Hjalmarsson写道： > Thanks for your report! > > I'm struggling to understand the nature of this issue. > > On 2022-05-01 21:36, Frank Dietrich wrote: > > Running `/usr/bin/emoji-picker` fails with `/usr/bin/sh: bad > > interpreter: No such file or directory` > > I can't reproduce that on my Debian testing, since I have the symlink > /usr/bin/sh (pointing to dash). Don't know how that symlink was created, > though. > > Actually I noticed a Lintian complaint about wrong path for interpreter, > but since I had both /bin/sh and /usr/bin/sh symlinks, I boldly added > this override: > > https://salsa.debian.org/input-method-team/ibus-typing-booster/-/commit/aeb751c3 > > Are you able to shed some more light on the topic? Actually I don't understand upstream commit 40718d5. Traditionally all POSIX- like distributions do support /bin/sh without any problem. However, given that Debian's usrmerge problem hasn't settled yet, using /usr/bin/sh will be broken on a non-usrmerge Debian system since /usr/bin/sh does not exist here. On the other hand, the switch to /usr/bin/sh does not bring any benefit (If you know _any_ benefit, please let me know), and I cannot understand why upstream would make such destructive commit to deliberately break compatibility. Anyway, this is now a real bug on Debian. P.S. POSIX did not state that /bin/sh or /usr/bin/sh is guaranteed to exist. [1] However, the traditional choice is to make sure that /bin/sh is always available. [1] https://pubs.opengroup.org/onlinepubs/009695399/utilities/sh.html Thanks, Boyuan Yang
Attachment:
signature.asc
Description: This is a digitally signed message part