Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]
* 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
Running update-shells in postinst and prerm (and never in the other two)
would additionally be required to ensure that /bin/sh is always