* Stephan Kulow <coolo(a)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
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
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
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org