[ It sucks to have to confirm mails for debian-package-d...@list.smarden.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 to me. > > 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 pointless. > 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! Cheers, -- Raphaƫl Hertzog 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/ -- 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/20100430062857.gc6...@rivendell