* 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 -- 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/20110405235520.ga5...@furrball.stateful.de
