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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
