Bug#575361: false positive: E: dash: package-uses-local-diversion
Gerrit Pape <pape@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: