Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]

[Carsten Hey <carsten@debian.org>]

* Luk Claes [2011-04-05 23:11 +0200]:
> On 04/05/2011 11:05 PM, Jonathan Nieder wrote:
> > Carsten Hey wrote:
> >> * Steve Langasek [2011-04-04 19:37 -0700]:
> >>> On Tue, Apr 05, 2011 at 02:00:36AM +0200, Carsten Hey wrote:
> >>>>  * Find a sane solution for managing /bin/sh.  Currently diversions are
> >>>>    used, which looks like the wrong tool for this job to me.  There are
> >>>>    also some related bugs with a high severity.
> >
> > The correct way to manage /bin/sh is as a configuration file.

Of course it is.

> >  * dash would stop shipping /bin/sh in its data.tar
> >  * bash would stop shipping /bin/sh in its data.tar

How would debootstrap be able to run the preinst scripts without
a working /bin/sh, unless it runs bash's binary one first?

> >  * an essential package (doesn't matter which --- maybe debianutils)
> >    should take care of allowing other shells to influence where
> >    /bin/sh points.

update-alternatives is (among other things) because of the indirection
it uses the wrong tool, but a part of it fits rather good.  Such a tool
would need to support priorities to select per default dash as /bin/sh,
if dash is not installed it would select bash and if both are missing it
would select an other shell.  It would also need to assure that whilst
it is running /bin/sh is always functional.  Passing a shell to it that
is not included in /etc/shells could lead to failing of this tool,
unless --force is used.

> Well, that will only happen when it's cristal clear that it's guaranteed
> that /bin/sh exists and is functional at all times in such a scenario.

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.

Running update-shells in postinst and prerm (and never in the other two)
would additionally be required to ensure that /bin/sh is always
functional.


Regards
Carsten