On Wed, May 15, 2013 at 03:39:54PM +0000, Thorsten Glaser wrote: > As for your requests of data: I do not provide them. As I said above, > I???m pushing for freedom of choice, not switching the default; of course > I???d be happy with the latter, even more so actually, but it must be a > thing not driven by me; if there???s enough other people (especially DDs) > interested in actually doing that it has potential to get taken a bit > seriously at all; if I???m involved, all bets are off (especially now, I > guess).
There are two issues you mix here: 1) Using mksh as /bin/sh by default. I see no issue with you providing the data. If mksh provides significant benefits, I guess others will jump on the boat as well. Just make sure to include the method of measurement, so others can reproduce the results. If all else fails, your data probably points out some weaknesses in dash, that can result in a better dash. 2) Making /bin/sh configurable. As I and a number of others have explained already, this choice comes at a cost. I'm inclined to say that this cost is even higher than just changing /bin/sh globally. So for this you need even better arguments, since it is hard enough to clean the current mess. The approach to just do the work is indeed a good argument. If the bash maintainer has indeed remained silent on your present work, you might need to take other measures to fix this rc bug in dash. For instance the ctte can be asked for advice (as opposed to overruling a maintainer). Thanks for your work here, I have long dropped this ball after running into silence on other involved parties. > > Using the diversion mechanism to change /bin/sh is highly risky and was > > never supported. > > Actually, dash uses a diversion too, so it was supported pretty well. I was not precise enough here. With "diversion mechanism" I meant local (i.e. admin controlled) diversion. This is broken precisely because dash is currently (ab)using diversions to change /bin/sh. It was never supported in the sense, that we left the corresponding bug open all the time and changed the release notes instead. So we basically meant the same thing. Helmut -- 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/20130516110528.ga14...@alf.mars