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

Niels Thykier niels at thykier.net
Fri Jan 9 16:26:09 UTC 2015


On 2015-01-08 22:23, peter green wrote:
> 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,
>>
>> [...]
> 
> 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.
> 

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.

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

Indeed.

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

I believe it is an RC bug in afterstep that does not comply with the
policy.  Robert seems to disagree having reassigned this back to
debhelper, reopened #766711 and opened #767839.

~Niels




More information about the debhelper-devel mailing list