[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Fwd: Re: Bug#575361: false positive: E: dash: package-uses-local-diversion



--------------- Forwarded message (begin)

Subject: Re: Bug#575361: false positive: E: dash: package-uses-local-
diversion
From: Raphael Geissert <geissert@debian.org>
Date: Wed, 28 Apr 2010 18:57:51 -0500
To: 575361-submitter@bugs.debian.org, 575361@bugs.debian.org

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


Reply to: