Bug#824011: warzone2100: FTBFS in testing (maybe missing Build-Conflicts)

[Markus Koschany]

Control: severity -1 normal

How come I am not surprised about your reaction and this reminds me of
the discussion we had about Bullet and the bug you eventually closed.
Again, if you disagree with maintainer decisions, then just don't raise
the severity again. Try to respect your fellow maintainers for once or
ask yourself if probably you are the one who has come to the wrong
conclusion. Not every bug is release critical.

Try to make your point but if the maintainer still disagrees and you
think he or she is totally wrong, please forward this issue to the CTTE.
Full stop. No severity bumping will ever make your argument right or
solve an issue quicker.

Am 16.05.2016 um 03:27 schrieb Santiago Vila:
> severity 824011 serious
> thanks
> 
> On Mon, May 16, 2016 at 02:17:23AM +0200, Markus Koschany wrote:
> 
>> I have just rebuilt warzone2100 in a clean sid cowbuilder chroot.
> 
> Well, if that's all you did, then I would say that you didn't
> understand the nature of the problem.
> 
> I'll try to explain better below.
> 
>> Everything went fine. Currently automake 1.11 is automatically installed
>> but this might change in the future so we should keep an eye on this
>> issue. I don't consider this to be release critical at the moment as
>> long as warzone2100 can be built from source in a default chroot
>> environment but I leave the rest to pabs, if he should feel differently
>> about that.
> 
> That's precisely the problem: chroots do *not* have to be "default",
> and that's precisely why Build-Conflicts exists at all.
> 
> Moreover, my chroot was pretty "standard" as it had debhelper installed
> by default, nothing really strange.
> 
> This is a FTBFS bug. Please read Debian Policy about Build-Conflicts
> before modifying severity again.

warzone2100 build-depends on automake1.11. I know the paragraph about
Build-Conflicts and I understand why the package FTBFS for you. My
conclusion is that warzone2100 simply requires automake1.11 to build.
Using Build-Conflicts would be one way to solve this issue for you, the
other one is to make the build system compatible with either of them.
You could also remove the other automake version from your chroot...


> I'll quote policy for you to save time:
> 
>   Build-Depends, Build-Depends-Indep, Build-Conflicts, Build-Conflicts-Indep
> 
>      Source packages that require certain binary packages to be installed
>      or *absent* at the time of building the package can declare
>      relationships to those binary packages.
> 
> This is the case here. This package requires normal automake to be
> *absent* because it needs automake1.11 and gets confused if there is
> another automake floating around.

Exactly, they _can_ declare relationships. No _must_ directive here. It
is not a Policy violation if you don't use Build-Conflicts. The package
builds fine from source in my environment and on the buildd. Thus it is
a bug when it FTBFS with another version of automake installed but not a
serious one.

I suggest to keep this bug report open but at severity normal and try to
fix this when upgrading to the latest upstream release which we should
do before the next freeze.

Regards,

Markus




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20160516/6b08c0cf/attachment.sig>