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-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
