Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]
* Luk Claes [2011-04-06 07:20 +0200]:
> On 04/06/2011 01:55 AM, Carsten Hey wrote:
> > Guaranteeing that /bin/sh exists and is functional during debootstrap,
> > even before any maintainer script has been run, could be archived if
> > every system shell would provide /bin/sh pointing to itself. To avoid
> > file conflicts, all but the one whose preinst is run first (finding
> > a clever way to detect this shouldn't be that hard) could divert their
> > /bin/sh to /bin/sh.$SHELL. When update-shell (or whatever it's name
> > would be) finally takes over managing /bin/sh, it could divert the
> > remaining /bin/sh away and replace it with a symlink not known to the
> > packaging system.
>
> That unfortunately does not work as diversions are only meant to be used
> when 2 packages provide the same file.
Actually, this impossible use of dpkg-divert was intended to be a way to
work around the missing (or unwanted?) hook support in deboostrap and
cdebootstrap. Packages in base could use these hooks to set up a part
of what is currently done in /usr/share/debootstrap/scripts/.
Without such hooks, adding /bin/sh could still be done in debootstrap
and cdebootstrap.
> One of the problems being what to do when you remove one of the shells
> (for instance the one providing /bin/sh)...
ksh's prerm script would call "update-shell remove /bin/ksh93". If
/bin/sh would point to ksh93, update-shell would change /bin/sh to point
to the registered system-shell with the highest priority.
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
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.
* Simon McVittie [2011-04-06 11:22 +0100]:
> > Passing a shell to it that is not included in /etc/shells could lead
> > to failing of this tool, unless --force is used.
>
> Not everything in /etc/shells is POSIXy enough to be /bin/sh.
This was not meat as whitelist but as "inverse blacklist" (everything
not in it is most probable not a adequate /bin/sh). Anyway, this was
a bad idea.
Regards
Carsten
Reply to: