[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: