On Mon, 16 May 2016, Markus Koschany wrote: > [...] 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.
This is not a conclusion of mine. FTBFS bugs are of serious severity, they have always been. > warzone2100 build-depends on automake1.11. I know the paragraph about > Build-Conflicts and I understand why the package FTBFS for you. It does not FTBFS "for me". It fails to build from source for *anybody* who has automake installed. Bear in mind that automake is not a random package, it's a dependency of debhelper, which is currently used by most packages in the archive. A chroot may have automake installed. Build-Depends is for packages that you need installed, but nowhere it's said that you can only install those, and this is why Build-Conflicts exist. > My conclusion is that warzone2100 simply requires automake1.11 to > build. That's not a good conclusion because it's incomplete. warzone2100 does not only need "automake1.11" to build, it also needs "automake" *not* to be present. > Using Build-Conflicts would be one way to solve this issue for you, Again, this is not a problem "for me" or "in my computer", it is a problem in the source package (otherwise I would not have bothered to report this as a bug). > the other one is to make the build system compatible with either of > them. Yes, we agree on that, you will notice I didn't say Build-Conflicts was the only solution, but it's certainly the easier. > You could also remove the other automake version from your chroot... Again, you put the blame on me, and talk as if this were "my problem" or as if I were part of the problem for having automake installed in my chroot, and not a problem in the package. I repeat: This is what Build-Conflicts is for. When a package needs another one to build, we put it in Build-Depends. When a package needs another one *not* to be present to build, we put in Build-Conficts. If you forget to put a package in Build-Depends, there is a FTBFS and you would not suggest people to install the package by hand to solve the problem, would you? I want to believe that you would add Build-Depends without much discussion. For the same reason, if you forget to put a package in Build-Conflicts, there is a FTBFS if the package is installed. Why, then, are you suggesting that I remove "automake" by hand? I'm just following simple logic here. If failure to declare a Build-Depends is a serious bug, failure to declare a Build-Conflicts should not be different, because the end result (a FTBFS) is the same. > > 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. Of course, you only declare relationships that you *need*. If your package does not need any relationship, there is no need to use any. Here, policy just explains the allowed vocabulary when writing control files, but does not say what you want to say with such vocabulary, that will depend on the actual needs of the package. In this case, we absolutely need automake not to be present, because the package FTBFS if it's present, and that's a real *need*, not just "you might better not to have automake installed". Otherwise: Are you trying to imply that Build-Depends are optional and you can tell people that they have to install packages by hand if a package fails to build from source? Would you tell someone that not using a required Build-Depends is not a serious bug because it's not a Policy Violation, because Policy just says you "can" use Build-Depends? That would be quite an unorthodox interpretation of Policy indeed.
