* Stephan Kulow <coolo@suse.de> [2010-03-25 10:19]:
So to summarize: with the hacks I applied /bin/sh symlink doesn't matter to boot time at all - that's what I always believed no matter what debian/ubuntu claimed.
Debian/Ubuntu have a different startup process, in Lenny parallel execution of boot scripts is still broken, so its possible that it will lead to minor speedups as they claim.
Of course it's little suprising, after all there are 35 /bin/sh processes and 66 /bin/bash processes according to preload trace. So even if we replaced the other 66 (a lot of those are user processes that are likely run with the login shell), still no gain.
So if performance is any kind of argument, I suggest Guido changes his monitoring scripts to use /bin/dash directly ;)
I already do that on my server since it's running Debian Lenny. However, I think we had agreed that performance was not the primary rationale. I don't know why everyone is so obsessed with this, bash is a nice interactive shell, but its performance and memory usage suck for not so simple use cases (and I think I demonstrated that for startup and subshell performance).
I still believe that we should treat bash scripts labeled as /bin/sh as bugs, but Michael is right that it doesn't justify a fatal error. Then again, we urgently need some kind of rpmlint statistic for our packages available.
It is a bug and it should be treated as such, particularly because changing #!/bin/sh to #!/bin/bash is not that difficult. I mean you also don't specify K&R mode if you want to compile C99? dash -n and checkbashism alone won't cut it, scripts need to be actually run and tested just as I test compiled binaries when packaging them. Without a packaging policy in place and the possibility to switch /bin/sh to dash, how will this happen and how will you avoid regressions, especially in maintainer scripts? I still think it is possible, certainly not before 11.3 but as a long term goal. However, at one point in time we need to say that all _newly written_ maintainer scripts must be tested with dash if they specify /bin/sh and that packages are tested on a system with /bin/sh pointing to dash. I don't think this would lead to that much work for package maintainers, but otherwise it would not make sense to gradually fix scripts as progress would be hampered by a continuous inflow of regressions. After making some serious progress /bin/sh could be managed by update-alternatives allowing those who oppose it being dash to keep bash. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org