Re: /bin/sh
Helmut Grohne <helmut@subdivi.de> writes:
> Using the diversion mechanism to change /bin/sh is highly risky and was
> never supported. Even if Debian only supports running dash (or bash) as
> /bin/sh and we ignore problems from broken scripts, there still is the
> breakage resulting from the diversion itself. As far as I can tell it
> still breaks dash upgrades in all cases. So even the ambitious user
> running mksh as /bin/sh and reporting patches for scripts using dashisms
> (I never imagined using that word), would be screwed with the next
> upgrade.
It only breaks dash upgrades right now because the Debian /bin/sh setup is
currently itself done with diversions, and therefore can't cope with a
local diversion that's other than what it expects.
At this point, regardless of any question about changing the default shell
or supporting local diversions, we probably want to back out of and
simplify the current default /bin/sh management to stop using diversions,
just for our own sanity.
> From my point of view a change in handling /bin/sh is highly desirable
> precisely now, because we all know that the current way is broken and it
> was that way for two releases already. Fixing it will cause other
> problems (unless all involved parties are geniuses), so fixing it early
> in the release cycle is important. As far as I can tell from the huge
> bug log partial fixes are already in place and patches are available for
> the remainders[1]. IMHO go ahead an break sid now? Waiting longer means
> never fixing it or dragging it into the next freeze.
Yes, it would be good to move away from using diversions early in the
release cycle.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: