Re: /bin/sh (was Re: jessie release goals)
On 2013-05-11 11:22 +0200, Goswin von Brederlow wrote:
> While that might be of some interest the real goal of the change was
> to be able to have more than *2* packages provide /bin/sh.
>
> Currently, due to the totaly screwed up way this is done, only dash or
> bash can be /bin/sh.
I think that dash could probably stop diverting /bin/sh, now that bash
no longer ships it (as of version 4.2-1). That would make it possible
to locally divert /bin/sh for those who want it (#538822, #540512).
> Double that for multiarch on amd64/i386 because there is bash:i386 and
> bash:amd64 that both work just fine as /bin/sh. Trying to install a
> foreign bash or dash fails horribly though with the current diversion
> hack.
Huh? No it doesn't, dpkg handles this just fine (apt doesn't because it
does not support crossgrades, but that is another story). Make sure you
have dpkg >= 1.16.2, though.
> Proposed solution:
>
> - New virtual package system-shell with something essential
> depending on it (base-files?)
Would probably need pre-depends so that system-shell cannot be removed
temporarily (similar situation as with awk).
> - bash, dash pre-depend on system-shell for the transition
>
> - new packages system-shell-<name>
> Provides, Replaces, Conflicts: system-shell
> contains /bin/sh -> /bin/<name> symlink
>
> None of system-shell-* would be essential but through the dependency
> of something essential at least one would always be installed
> (pseudo-essential). One of them (system-shell-dash) should have a
> higher priority than the rest to be singled out as the default and
> the essential package would depend system-shell-dash | system-shell.
>
> Choosing /bin/sh is then simply done by installing the right package
> and dpkg does the change atomically.
Only if the packages declare Conflicts/Replaces on every real provider
of system-shell, and with apt you lose outright because it insists on
removing the conflicting package(s) first.
> No messing around in
> pre/postinst/rm scripts or race conditions where the link might
> disapear for a while. No artificial limit on how many system-shell-*
> packages there could be.
I'm afraid your plan as outlined is not going to work.
Cheers,
Sven
Reply to: