Re: Comments on the "Changing the default system shell" talk
Hi,
I haven't jumped into this discussion it but it starts annoying me...
On Sun, 26 Jul 2009, Goswin von Brederlow wrote:
> The choice being that the admin may dpkg-divert /bin/sh to whatever
> shell he wants and he then can fix whatever breaks. Great. We already
> have exactly that now. There is nothing added. No mechanism and no
> assurances that things won't break.
Things might break when you update the link automatically during upgrades.
By limiting the number of packages that could fiddle with the link, we do
keep things robust. Officially supporting a wider choice for /bin/sh would
be more likely to lead to breakages.
I'm happy to leave it to admins to assume any other choice.
You can certainly create an helper tool that helps you change the /bin/sh
link while still keeping things working. The helper tool would create
a package that pre-depends on the selected shell and does the required
dpkg-divert commands (those created packages would provide "default-shell"
and conflits against "default-shell" to ensure only one of them is
installed).
That doesn't need to be coupled to the current project of changing
the /bin/sh symlink. So stop bringing this up and create that helper tool
if that's what you're looking for.
> You say that the default /bin/sh must be an essential package as only
> way to make sure it is always present. That is clearly wrong and we
> have mawk/gawk as a real life example of having something always
> installed (awk) while still keeping the choice open.
I think we already told that we do not want to use update-alternatives for
the /bin/sh symlink.
> 2) You are bloating the system and essential packages list
The size increase caused by dash is largely compensated by the other
speed benefits. Calling that bloat is counter-productive discussion.
If you really believe it's bloat, you should just try to remove
bash from the essential packages (it's doable in the long term).
> Will it eventually be policy that essential/required/standard packages
> must not depend on bash? Because as long as something in the core
> packages depends on bash it will remain non removable.
Go push forward that policy item. You don't get to enforce someone else
pushing it for you as a precondition for their work.
Cheers,
--
Raphaël Hertzog
Reply to: