On 9/24/21 00:23, Ludwig Nussel wrote:
Thorsten Kukuk wrote:
On Thu, Sep 23, Michal Suchánek wrote:
On Wed, Sep 22, 2021 at 10:52:01AM +0200, Manfred Schwarb wrote:
Am 22.09.21 um 10:18 schrieb Adam Majer:
On Tue, Sep 21, 2021 at 11:01:46AM +0200, Manfred Schwarb wrote:
Am 21.09.21 um 10:47 schrieb Manfred Schwarb: > But the question remains: what about performance? > If I have a small program that is called in a loop, is performance severely hampered?
Your bottleneck will be an additional exec() call. If that is a signifiant overhead in the execution path, then your execution path already had it as a significant overhead.
But I would not recommend doing things like abstracting /bin/sh in this manner. Symlinks still have their place.
OK, then I misunderstood something. I thought the intention was to replace all alternatives handling with libalternatives, i.e. also for potentially often called binaries as ksh or awk.
Yes, the intention is to replace update-alternatives. But not in all usages, that's impossible to do. For some problems we need other solutions, like for /bin/sh.
IMO we should neither use libalternatives nor update-alternatives for such core tools like /bin/sh. If there's an actual use case for building systems that need different implementations we can still solve that with conflicting packages. In case of /bin/sh I think container images by default use busybox as /bin/sh. Some workloads still also need bash though. Regular openSUSE installations always use bash. So my suggestion would be to - package "bash" without /usr/bin/sh - subpackage "bash-sh" that has a symlink /usr/bin/sh pointing to bash - "busbyox-sh" that has /usr/bin/sh pointing to busybox - both "bash-sh" and "busybox-sh" need to conflict and provide some common tag then. Maybe alternative(sh)? - patterns-base-base which requires "bash" would has to require "bash-sh" too.
I'd probably go for patterns-base-base requiring the common tag and suggesting bash-sh which should have the same effect and won't cause conflicts with the pattern if someone wants to try something else. I also really like this idea, my interest in this concept comes from speeding up the build of slower packages, for these packages make often spawns alot of instances of /bin/sh so being able to BuildRequire: dash-sh on say a kernel spec file to first check it still builds and then see if the performance benefits are worth keeping. Cheers Simon -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B