Re: /bin/sh (was Re: jessie release goals)
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/
Reply to: