[debhelper-devel] Bug#766795: afterstep binnmu related issues

[Robert Luberda]

Niels Thykier writes:
>>
>> * I discovered that afterstep was uninstallable and not binnmu safe and
>> filed a bug.

Yes, Peter discovered that afterstep 2.2.12+b2 was uninstallable
indeed.

>> * The maintainer of the afterstep package blamed debhelper and
>> reassigned and merged my bug. 

Yes, as there were no such problems with the first binNMU of afterstep
(2.2.12+b1), the conclusion was quite obvious to me: it was debhelper
that caused the afterstep's installation failure by introducing
backward-incompatible change.

>> He also stated he would upload a
>> "workaround" of removing misc-depends. Soon afterwards he uploaded a
>> workaround

And now afterstep can be safely binNMU-ed again.


>> * 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.

Yes, sorry, I must have missed the mail of Julien. I've just read it on
BTS web page, and noticed that it does contain no explanation why the
work-around was unacceptable. Please note that the issue had came up a
week or so before the freeze, and in my opinion implementing the
work-around was the best action I could take at that moment.

>> * the debehlper maintainers declared that link-doc between arch any and
>> arch all packages was unsupported and took steps to explicitly block
>> such binnmus.

As I explained above (2.2.12+b1 case) debhelper actually used to support
this.

>> * There  were some problems with the blocking code and it was reverted.

Was the change that broke backward compatibility (the one which touches
${misc:Depends}) reverted as well?

> 
> Indeed.  Note that the "blocking code" is still enabled for compat 10
> and debhelper will emit warnings at compat 9 (and earlier) when using
> --link-doc between arch:all and arch:any pacakges.  The only reason for
> not completely rejecting them now is that too many packages are using
> them (incorrectly) already now and binNMUs are not frequent enough to
> warrant that many FTBFS now.

Please correct me if I'm wrong, but this all means that those `too many
packages' that depend on previous behaviour of debhelper cannot be
safely binNMU-ed in jessie. In theory it might happen that e.g. security
upgrade of some package will require rebuild of all it dependencies, I
guess.

> 
> I believe it is an RC bug in afterstep that does not comply with the
> policy. 

I disagree it does not comply with the policy, see my other mails for
reasoning.

> Robert seems to disagree having reassigned this back to
> debhelper, reopened #766711 and opened #767839.

It was Peter who reopened 767839, re-assigning was done by me: thanks to
the work-around afterstep *is* currently binNMU safe. However this is
only `work-around', which means that even me is not fully glad of this
solution, and I promise to fix it one way or another for jessie+1.

Regards,
Robert