Carsten Hey <cars...@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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bp0igye5.fsf@frosties.localnet
