Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]
Carsten Hey <carsten@debian.org> writes:
> System shells would (de)register themselves by calling add-system-shell
> in postinst and remove-system-shell in prerm. 'system-shell' would also
> be a virtual package provided by bash, dash and so on. Although I don't
How would that work with (c)debootstrap/multistrap when creating a
chroot for a foreign architecture? No maintainer script will be run in
those cases nor can they be run in general.
Some package needs to initially ship a /bin/sh binary or symlink, which
I would think dash should do (being the default sh). And the registering
in postinst could then later replace this with the proper mechanism
(which would still just be a symlink to dash by default I guess).
> think this would be a problem, using /bin/$SHELL in the shebang of
> postinst and prerm could prevent possible problems if /bin/sh changes
> whilst these scripts are running.
In postinst and prerem there is no problem in using /bin/$SHELL since
the shell is already/still present. But what about preinst and postrm?
We can probably assume there will allways be one system shell present so
/bin/sh for postrm is fine. But for preinst we are back to the above
problem. When bootstraping no postinst of any system shell has yet run
so there is no /bin/sh configure. Yet we still need one. Even using an
elf binary as preinst to create the initial /bin/sh link would be ugly
because then bootstraping tools (second stage) need the special
knowledge to run that first.
Which brings us back to the need for some (dash :) package to ship an
initial /bin/sh before the proper (de)registering mechanism takes over.
Please keep that in mind when designing it.
MfG
Goswin
Reply to: