Re: dash Debian package - RC bugs
On 29 April 2010 14:23, Raphael Hertzog <hertzog@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
Reply to: