On Fri, Oct 08, 2010 at 11:02:22PM -0500, Jonathan Nieder wrote: > A somewhat orthogonal task > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > IV. Introduce a new package to take responsibility for the /bin/sh symlink. > > Preinst (not necessarily in this order): > 1. Removes all diversions > 2. Sets up a diversion > 3. Makes sure /bin/sh points to the same place at the > beginning and end. > Debconf prompt lets a person choose what shell to use. > Postinst makes sure /bin/sh points to the configured place. > > It is be hard to get this right while avoiding file conflicts > until only one package provides /bin/sh, but it should be possible > to experiment on lenny. > > V. Teach shells to rely on the package from (IV) for configuration.
Hi Jonathan, this roughly is the design I had in mind, but people started a different implementation back than, adjusting the diversion handling in the maintainer scripts. Since then I wait for them to either complete the task (I never signed up for it), or give up. In my opinion adding the same diversion handling to mksh was a bad move, diversions only work for exactly one package, so mksh actually needs to conflict with dash. Herbert added this diversion handling to dash in 2001. If a new package is introduced that takes over /bin/sh, it needs to guarantee than some working /bin/sh symlink always exists. In the end no more diversions should be involved, and for upgrades the new package can record where /bin/sh points to, and remove the diversion without changing the symlink. A debconf question to choose where /bin/sh points to sounds reasonable, even though I'm not a fan of debconf. If this all is done correctly, we nearly have a new and robust implementation of update-alternative. The current one isn't an option because people are not sure that it always does the right thing, here: guarantee that a working alternative always exists. I doubt though, that these changes can go into squeeze that late. Thanks a lot for your contributions. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
