Re: dash Debian package - RC bugs
[ It sucks to have to confirm mails for firstname.lastname@example.org ]
On Thu, 29 Apr 2010, Raphael Geissert wrote:
> > 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.
Didn't you had problems with partial upgrades when moving the file from
one package to the other ? Or did you plan to add a dependency from bash
to dash ?
> 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.
If that's really the only problem left, I think you are entitled to take
whatever decision you think is the best. Both approaches seem reasonable
> > 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.
Shipping in a package works but I wonder if you can still guarantee that
when moving the file from one package to the other without creating
dependencies that some people will dislike.
> > 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."
Well, that idea was based on the premise that we can't safely move the
/bin/sh symlink from one package to the other without risking loosing it
at some point.
It the premise does not hold true, then of course the whole idea is
> 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 :)
Just go ahead!
Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/