On 15 Nov 2018, at 16:04, Daniel Glassey <w...@debian.org> wrote: > On Thu, Nov 15, 2018 at 5:57 PM James Clarke <jrt...@debian.org> wrote: >> On Thu, Nov 15, 2018 at 11:59:40AM +0700, Daniel Glassey wrote: >> > Package: ftp.debian.org >> > Severity: normal >> > >> > bibletime 2.11.2 only builds on amd64 arm64 armhf i386 mipsel >> > bibletime 2.10.1 is still in unstable for the other archs. It depends on a >> > version of libsword11v5 that does not contain the lib that it was >> > linked against so is unusable. (same as #913070) >> >> This request doesn't at all make sense and highlights a bug in your >> package. >> >> Firstly, the fact that 2.10.1 depends on libsword11v5 is irrelevant, but >> does explain why libsword11v5 is still in the archive despite >> libsword-1.8.1 being the new package name. > > It isn't irrelevant but hopefully the upload to come will make it so, so no > need for me to explain. > >> Secondly, why is it that bibletime is limited to these few >> architectures? In the changelog and your commit you say "update >> architectures to satisfy policy 5.6.8", which is completely useless >> (*why* can we only ever build on those architectures?), and policy has >> this to say: >> >> > Specifying a list of architectures or architecture wildcards other >> > than any is for the minority of cases where a program is not portable >> > or is not useful on some architectures. Where possible, the program >> > should be made portable instead. > > BibleTime was changed for version 2.11 to use Qt5 instead of Qt4 including a > build-dep on qtwebengine5-dev. > > libqt5webengine is only available on those 5 archs so it is all that > bibletime 2.11.2 built on.
So? Build dependencies not being available is not a reason to limit the Architecture field. The *only* reason to have an architecture whitelist is if your package has lots of architecture-specific code and there is no way it could ever work on a different architecture without large changes *to the package itself*. It's always better to use "any" if in doubt; either the build will fail, so porters are aware the package needs fixing, or it has a build dependency on something not currently built, and so will just wait until the dependency is built (drawing attention to the fact that that dependency is important). >> Is bibletime really that non-portable? The list of architectures seems >> extremely specific and unlikely, especially given that bibletime has >> previously successfully built on many other architectures than these. >> Unless bibletime has architecture-specific assembly or similar, put this >> back to "any" and this RM should no longer be necessary. > > But I've found that it turns out that it is supposed to work with qtwebkit5 > an alternative to qtwebengine5 so I'll close this bug with an upload with an > alternative build-dep on qtwebkit5-dev and see how it goes. Alternative build dependencies are discarded by wanna-build so that doesn't actually let the package build on architectures with libqt5webkit5-dev. If you want to use qtwebkit on some architectures, you need the appropriate architecture restriction lists in your Build-Depends field. James
