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

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 :)

Raphael Geissert - Debian Developer
www.debian.org - get.debian.net

Reply to: