Hi Thorsten On 11-05-13 20:26, Thorsten Glaser wrote: > Steve Langasek <vorlon <at> debian.org> writes: > >> This is not a sensible goal. Choice of /bin/sh should *not* be the goal, >> the goal should be to get a good, fast, minimal, policy-compliant /bin/sh >> for *everyone*. > > Sure. We just disagree which one that is. > >> See also: Linux is not about choice. > > Debian is not just about Linux.
While a choice of $SHELL is useful for a user and something we should support (through things like chsh), I fail to see how a choice of /bin/sh is extremely critical. I also fail to see how the above statement factors in this entire discussion. > Oh, sorry, I forgot, you work for Canonical (which totally explains some > of your writings in the other eMail too, which I’m not going to comment > on). Of course, for *buntu people it’s not about choice. This is an ad-hominem attack, which has no place on -devel. Please take that elsewhere (/dev/null, preferably). [...] > In Debian, Developers are also users, and it can only be the > UNIVERSAL operating system when there is choice. Wrong. >> Yes, the diversion hack should be superseded by a single, static symlink >> belonging to the dash package > > Why dash? It’s clearly inferiour, buggy and not taken care of well. Because at the time this decision was taken, dash was the only available candidate. [...] > choose their system shell. I don’t even care about the default, > I’d be happy were it mksh or mksh-static of course, but I don’t. > And I’ve successfully run both Debian and Kubuntu with mksh as > system shell.) All else being equal, you're right that a choice of shell for /bin/sh is a good thing, and you're also right that changing /bin/sh to some other implementation usually doesn't bring with it any negative effects once it's done. In fact, policy requires that this is possible. However, all else is *not* equal. Contrary to the awk situation, large parts of the Debian packaging format rely on /bin/sh functionalty, and will break (and leave the system in an inconsistent state) if /bin/sh is nonexistent at the wrong moment. I'm not saying it's impossible to implement this the right way, but doing so will cause a lot of pain and a lot of problems before we get there. That is precisely why the /bin/sh change was implemented with a diversion rather than an alternative; the latter is much more fragile and brings with it a much larger risk of screwing the user over and leaving them with a system that won't boot, and can't easily be fixed by just doing "dpkg --configure -a". This is a *bad* thing. For an issue that few of our users care about, it is questionable to risk so much. In addition, people who know enough about the issue to want to switch /bin/sh away from dash and to another implementation usually also are knowledgeable enough to just call the "ln -sf" command manually. We might wish to document the circumstances under which this is a safe thing to do (and why the alternatives system isn't used), but that's about it. >> No, it is NOT about choice. It is about providing a high quality, free >> operating system to our users. This ridiculous complexity in /bin/sh > > But your users may have a more broad horizon than you, as Canonical > employee, can imagine. Having met Steve in person and talked with him on multiple occasions, I can assure you that there are few people in Debian who have as broad an understanding of the needs of the Debian (and by extension, Free Software) community and its users. This remark is insulting and not based in fact. Please retract it. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- 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/5194c192.60...@debian.org
