Bug#575361: false positive: E: dash: package-uses-local-diversion
Russ Allbery wrote:
[...] my understanding is that, in prerm, you're already checking
that dash owns the diversion:
div=$(dpkg-divert --list $1)
if [ -n $div ] [ -z ${div%%*by dash} ]; then
distrib=${div% by dash}
distrib=${distrib##* to }
mv $distrib $1
dpkg-divert --remove $1
fi
If I'm right, then while it isn't necessary, it would remove the Lintian
warning and make it clearer for anyone reading prerm if you could write
the dpkg-divert --remove line as:
dpkg-divert --package dash --remove $1
instead. In fact, I'm not entirely sure why that whole block isn't
replaced by just:
dpkg-divert --package dash --rename --remove $1
which should be roughly equivalent, but presumably there was some reason
why that didn't work?
That piece of code comes from the pre-NMU prerm (it was not touched at all
by the NMU.)
But I agree, it could be rewritten by using --package. Since dash now
depends on a version of dpkg that supports --packagename the code block
could be rewritten as:
diverter=$(dpkg-divert --packagename $1)
if [ $diverter = dash ]; then
dpkg-divert --package dash --rename --remove $1
fi
(calling dpkg-divert --remove unconditionally would lead to an error message
.)
The postinst case is somewhat more complicated, and there, it really does
look like the package is overriding local diversions in one place if the
user answers yes to the debconf prompt. The first block of check_divert
does appear to be exactly the thing that Lintian is meant to warn about.
I think the intention was to remove the diversion no matter what package
created it, but not necessarily to remove local diversions. If I'm right,
changing that dpkg-divert --remove invocation to:
dpkg-divert --package $sh_diverter --remove $2
should be completely equivalent for that use case but fail to remove local
diversions (which is probably the safe behavior since something strange
may be happening if you have a local diversion).
It does remove local diversions, indeed. However, I think it is fine that
the maintainer script is doing it.
The user is prompted whether she/he wants to switch to dash, if the answer
is yes then dash does as requested: makes /bin/sh point to dash.
Similarly, in the third case you've already confirmed that the owner is
ash, so changing that dpkg-divert to:
dpkg-divert --package ash --remove $2
should fix the Lintian tag.
Yes, although I think it is more than time to cleanup the maintainer scripts
and remove the ash-dash transition code. Don't you think, Gerrit? it is at
least already in etch's version, not sure about sarge's.
If the above changes seem okay to you, the fastest way to fix this is
probably to make them, but if you feel strongly that you shouldn't need to
do so, I'm happy to discuss this analysis with the ftpmasters to see if
they'll make that tag overridable.
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?
Gerrit, I'm going to publish my repository with changes addressing the dpkg-
divert issues somewhere. Will follow up on that on the other thread.
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
--
To UNSUBSCRIBE, email to debian-bugs-dist-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 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-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575361: false positive: E: dash: package-uses-local-diversion
On Thu, Mar 25, 2010 at 11:43:28AM -0700, Russ Allbery wrote: Gerrit Pape p...@dbnbgs.smarden.org writes: Hi, to me this looks like false positives. With the current dash and ash packages in squeeze: The code handling the diversion in these scripts is years old, and I never saw a local diversion created by them, nor received any bug reports about that. This may be a case where Lintian is just completely baffled by what you're doing, but let me explain what's going on and see if it makes sense. Hi Russ, sorry, I stole your time. I recalled I never really changed the diversion handling after taking over the package from Herbert in 2004. It was still Herbert's code, which simply worked over all the years. I forgot about the NMU to 'Change the default for the system shell to dash' from Luk Claes and Raphael Geissert. That's where the changes to the diversion handling come from, so lintian might quite well be right. Unfortunately it looks like they don't catch up on the resulting problems. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575361: false positive: E: dash: package-uses-local-diversion
Package: lintian Version: 2.3.3 Hi, to me this looks like false positives. With the current dash and ash packages in squeeze: $ lintian /var/cache/apt/archives/dash_0.5.5.1-3_powerpc.deb W: dash: spelling-error-in-changelog explicitely explicitly W: dash: missing-debconf-dependency E: dash: postinst-does-not-call-updatemenus usr/share/menu/dash E: dash: package-uses-local-diversion prerm:15 E: dash: package-uses-local-diversion postinst:11 E: dash: package-uses-local-diversion postinst:23 E: dash: package-uses-local-diversion postinst:45 E: dash: orphaned-diversion * postinst $ lintian /var/cache/apt/archives/ash_0.5.5.1-3_all.deb W: ash: spelling-error-in-changelog explicitely explicitly E: ash: depends-on-essential-package-without-using-version pre-depends: dash E: ash: package-uses-local-diversion postinst:23 E: ash: orphaned-diversion * postinst $ The code handling the diversion in these scripts is years old, and I never saw a local diversion created by them, nor received any bug reports about that. Unfortunately a new upload of the dash package without any changes in these scripts is currently auto-rejected because of this. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575361: false positive: E: dash: package-uses-local-diversion
Gerrit Pape p...@dbnbgs.smarden.org writes:
Hi, to me this looks like false positives. With the current dash and
ash packages in squeeze:
$ lintian /var/cache/apt/archives/dash_0.5.5.1-3_powerpc.deb
W: dash: spelling-error-in-changelog explicitely explicitly
W: dash: missing-debconf-dependency
E: dash: postinst-does-not-call-updatemenus usr/share/menu/dash
E: dash: package-uses-local-diversion prerm:15
E: dash: package-uses-local-diversion postinst:11
E: dash: package-uses-local-diversion postinst:23
E: dash: package-uses-local-diversion postinst:45
E: dash: orphaned-diversion * postinst
$ lintian /var/cache/apt/archives/ash_0.5.5.1-3_all.deb
W: ash: spelling-error-in-changelog explicitely explicitly
E: ash: depends-on-essential-package-without-using-version pre-depends: dash
E: ash: package-uses-local-diversion postinst:23
E: ash: orphaned-diversion * postinst
$
The code handling the diversion in these scripts is years old, and I
never saw a local diversion created by them, nor received any bug
reports about that.
This may be a case where Lintian is just completely baffled by what you're
doing, but let me explain what's going on and see if it makes sense.
Lintian's specific concern is not that you're *creating* a local diversion
but that, as far as it can determine, you may be *removing* local
diversions. Debian packages are supposed to never remove local diversions
created by the sysadmin. The specific lines that it is complaining about
look like:
dpkg-divert --remove $1
which will remove both package and local diversions.
The orphaned diversion tags are then due to bugs in Lintian because
Lintian doesn't consider what it thinks are local diversions when tracking
whether created diversions are removed. We'll fix that.
My understanding of shell substitution patterns isn't what it ideally
should be, but my understanding is that, in prerm, you're already checking
that dash owns the diversion:
div=$(dpkg-divert --list $1)
if [ -n $div ] [ -z ${div%%*by dash} ]; then
distrib=${div% by dash}
distrib=${distrib##* to }
mv $distrib $1
dpkg-divert --remove $1
fi
If I'm right, then while it isn't necessary, it would remove the Lintian
warning and make it clearer for anyone reading prerm if you could write
the dpkg-divert --remove line as:
dpkg-divert --package dash --remove $1
instead. In fact, I'm not entirely sure why that whole block isn't
replaced by just:
dpkg-divert --package dash --rename --remove $1
which should be roughly equivalent, but presumably there was some reason
why that didn't work?
The postinst case is somewhat more complicated, and there, it really does
look like the package is overriding local diversions in one place if the
user answers yes to the debconf prompt. The first block of check_divert
does appear to be exactly the thing that Lintian is meant to warn about.
I think the intention was to remove the diversion no matter what package
created it, but not necessarily to remove local diversions. If I'm right,
changing that dpkg-divert --remove invocation to:
dpkg-divert --package $sh_diverter --remove $2
should be completely equivalent for that use case but fail to remove local
diversions (which is probably the safe behavior since something strange
may be happening if you have a local diversion).
In the second case, you've already confirmed that the owner of the
diversion is dash, so as with the prerm, explicitly writing:
dpkg-divert --package dash --remove $2
would fix the Lintian tag.
Similarly, in the third case you've already confirmed that the owner is
ash, so changing that dpkg-divert to:
dpkg-divert --package ash --remove $2
should fix the Lintian tag.
Does this make sense? I'm sorry about the hassle; I think that of the
four cases there, only one is arguably a bug, and the other three are
cases where the maintainer scripts in dash are doing what dpkg-divert
would do in a different way and hence are really false positives.
Although I do think as a matter of style that adding the --package option
is a good idea.
Unfortunately a new upload of the dash package without any changes in
these scripts is currently auto-rejected because of this.
If the above changes seem okay to you, the fastest way to fix this is
probably to make them, but if you feel strongly that you shouldn't need to
do so, I'm happy to discuss this analysis with the ftpmasters to see if
they'll make that tag overridable.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
