Bug#575361: Fwd: Re: Bug#575361: false positive: E: dash: package-uses-local-diversion
Raphael Geissert atom...@gmail.com writes: I think it is fair to say that it is ok to remove a local diversion if the user is saying that she/he wants dash to be /bin/sh. Not doing so would even leave the diversion and debconf db in an inconsistent state. So, Russ, do you agree that package-uses-local-diversion is certainty: possible and that we should ask the ftp-masters to move it to the non- fatal list of tags? I'm not sure. I think a case could be maken that local diversions should never be overridden by maintainer scripts, period. I'm not sure which of those principles should hold more weight. All of the scenarios in which this would make a difference feel somewhat artificial, since I'm not sure why anyone would be using local diversions in the first place for this, but I could tentatively construct a scenario where someone is using the same debconf preseeding files everywhere but wants to explicitly override /bin/sh to be /bin/ksh or something on one host that's using that shared debconf preseeding. Note that with preseeding the user may not have just been asked, and we may be talking about large-scale automated deployment that doesn't involve anyone looking at prompts. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575361: Fwd: Re: Bug#575361: false positive: E: dash: package-uses-local-diversion
On 28 April 2010 21:13, Russ Allbery r...@debian.org wrote: Raphael Geissert atom...@gmail.com writes: I think it is fair to say that it is ok to remove a local diversion if the user is saying that she/he wants dash to be /bin/sh. Not doing so would even leave the diversion and debconf db in an inconsistent state. So, Russ, do you agree that package-uses-local-diversion is certainty: possible and that we should ask the ftp-masters to move it to the non- fatal list of tags? I'm not sure. I think a case could be maken that local diversions should never be overridden by maintainer scripts, period. I'm not sure which of those principles should hold more weight. And in that case we could argue that the user has already made her or his choice by adding a local diversion, yes. In that case some sort of hack could be used to set dash/sh to false while retaining the seen flag to false. All of the scenarios in which this would make a difference feel somewhat artificial, since I'm not sure why anyone would be using local diversions in the first place for this, As a matter of fact, using a local diversion to change /bin/sh is supposed to be the only supported method to do it. This is at the moment not true with the current dash package because it adds an diversion on its own and there can't be two diversions for the same package (that's one of the issues that need to be fixed.) but I could tentatively construct a scenario where someone is using the same debconf preseeding files everywhere but wants to explicitly override /bin/sh to be /bin/ksh or something on one host that's using that shared debconf preseeding. Note that with preseeding the user may not have just been asked, and we may be talking about large-scale automated deployment that doesn't involve anyone looking at prompts. True. One possible solution I can think about is to ignore/bypass the package-uses-local-diversion check for now and later handle the issue when bash is the one that has to divert /bin/sh. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575361: Fwd: Re: Bug#575361: false positive: E: dash: package-uses-local-diversion
Raphael Geissert geiss...@debian.org writes: One possible solution I can think about is to ignore/bypass the package-uses-local-diversion check for now and later handle the issue when bash is the one that has to divert /bin/sh. I think it would be reasonable to just bail if a local diversion is set with some sort of message saying that nothing is being done. That message could be missed and people would then be confused about what's going on, but my personal initial feeling is that that's slightly better than removing the local diversion. It all feels very thinly balanced to me, though. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
