[debhelper-devel] Bug#766795: afterstep binnmu related issues (was: debhelper: Dependency added by dh_installdocs --link-doc breaks binary-only NMUs)

[peter green]

unmerge 766795
reassign 766795 afterstep
tags 766795 -wontfix -patch -jessie-ignore
retitle 766795 afterstep not binnmu safe
thanks.

Niels Thykier wrote:
> Hi Robert, Simon and Axel,
>
> It is not possible for debhelper to provide a *policy compliant*
> link-doc *between arch:all and arch:any* packages under binNMUs[1].
> Accordingly, the use of --link-doc between such packages now triggers a
> warning (or a flat error under compat 10).
>
> I have taken the liberty of marking the bug as wontfix (read: "cantfix")
> and closing it.
>   
Unmerging the afterstep bug, removing the tags it picked up as part of 
the merge and returning it to the afterstep package.

The story so-far as I understand it

* I discovered that afterstep was uninstallable and not binnmu safe and 
filed a bug.
* The maintainer of the afterstep package blamed debhelper and 
reassigned and merged my bug. He also stated he would upload a 
"workaround" of removing misc-depends. Soon afterwards he uploaded a 
workaround
* jcristau (who I assume was wearing a release team hat) declared that 
this workaround was unacceptable and that the package must be fixed to 
not use link-doc between arch dependent and arch independent packages. 
The afterstep maintainer did not appear to respond to this.
* the debehlper maintainers declared that link-doc between arch any and 
arch all packages was unsupported and took steps to explicitly block 
such binnmus.
* There  were some problems with the blocking code and it was reverted.

So the afterstep binary package has a manual dependency on the data 
package which is strictly versioned on on the source version. The other 
binary packages don't seem to be using link-doc. Building a binnmu will 
result in dependencies that the debhelper maintainers claim are not 
policy compliant.

I have not altered the serverity of the bug. Personally i'm on the fence 
as to whether the bug in it's present state (essentially a latent bug if 
anyone builds a binnmu) is rc or not but i'll leave the descision to others.