[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: