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

[Niels Thykier]

On 2015-01-09 23:22, Robert Luberda wrote:
> Niels Thykier writes:
> [...]
>>> * 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.
> 

I strongly suspect the change that you consider backwards incompatible
would be this one:

https://anonscm.debian.org/cgit/debhelper/debhelper.git/commit/?id=f7324fa4c4fd41f8727e74bc0d5ef40b624ce878

"""
dh_installdocs: When doc dirs are symlinked make the dependency
versioned per policy. Closes: #676777
"""

Prior to that commit, debhelper would make unversioned dependencies,
which are not policy compliant.

For reference, the version chosen back then does have its issues.  In
the first upload for stretch debhelper will be using ${binary:Version}
instead.  See #747141.

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

... while keeping --link-doc.  For reference, we are debating a disk
cost of 1.3Mb right now.

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

No, it made dependencies that were not compliant.  You happened to have
a additional dependency that mostly covered the issue.

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

No, that cannot be reverted as it would break policy compliance.  It was
altered to use ${binary:Version} instead - but it will not help your case.

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

Yes.  Note that the bug was tagged jessie-ignore (until it was umerged
and ping-pong'ed between afterstep and debhelper).

> In theory it might happen that e.g. security
> upgrade of some package will require rebuild of all it dependencies, I
> guess.
> 

If that happens they can be manually uploaded to fix the issue.  That
said, it is unlikely for Debian to accept such changes in stable
releases, since binNMUs are most often used for ABI changes - a thing
not done lightly in a stable release.

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

I said you reopened #766711, not #767839, and reassigned #767839 back to
debhelper.  Right now debhelper has both #766711 and #767839 - it is not
clear to be that they are distinct bugs.  I will probably merge this one
into the other.

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

Ok.

~Niels