On 29 April 2010 14:23, Raphael Hertzog <hert...@debian.org> wrote: > On Thu, 29 Apr 2010, Raphael Geissert wrote: >> Any dpkg maintainer reading? Raphaël? Guillem? > > Yes, but I don't know what you expect from me. That discussion dragged for > far too long in too many directions.
Hum, ok. That's why I didn't CC the dpkg ML: the message would not make sense without the complete context. > What happened to the idea of having /bin/sh -> dash hardcoded in the dash > package instead ? That's still the plan. The problem is that once dash is the only package shipping /bin/sh, bash would be the one prompting the user whether she/he wants to use bash (so that the diversion is added) it would still break in case the user already added a local diversion. So this is a problem between dpkg-divert and debconf. Based on the discussion from the bug report (#575361), it appears that there's a compelling reason not to remove a local diversion no matter what the user answers to the debconf prompt. One possible solution is to skip all the debconf logic in case there's a diversion not owned by the package, but I 'm not sure that's the best approach. > Or maybe have it owned by no package and all handled in maintainer > scripts ? That's risky. If for any reason the code fails the system could be left without a /bin/sh. Nobody wants that. Shipping /bin/sh in one of the packages guarantees that. > New idea: maybe we need one more indirection since removing /bin/sh from > bash is problematic. We could invent /bin/default-shell that is handled by > maintainer scripts and a common debconf question shared by all shells that > want to be /bin/sh and modify bash (and dash?) to have /bin/sh point > unconditionnaly to /bin/default-shell instead. I don't think that adding another level of indirection would be of any help. And the approach you are proposing is basically what dpkg-alternatives does and that's been discarded in the past for being "too fragile for /bin/sh." If I were to decide, I think I would chose the "ignore debconf stuff if there's a diversion not owned by the package" approach. I'm of course open to discuss the whole situation (like we are doing right now :) Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- 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/x2qe9fb436d1004291246j2e6f00a7s2eef44b73b8bd...@mail.gmail.com
