* 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 -- 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/20110407000526.ga27...@furrball.stateful.de
