Control: reassign -1 googletest 1.8.0-3 Control: affects -1 apt On Thu, Dec 01, 2016 at 10:37:59AM +0100, John Paul Adrian Glaubitz wrote: > src:apt is currently BD-Uninstallable on alpha, m68k, sh4 and sparc64 because it > has a build-dependency on googletest which is not available on these architectures We used to depend on libgtest-dev before (and still do in or-fallback) and that worked so I would hope any problem can be resolved on their side as apt is hardly the only package build-depending on it… I had the impression in #844721 that this transition was a bit rushed perhaps due to inexperience and not considering all consequences, but the response was quick so lets at least ask before giving up, shall we? > because the code is buggyt (over 300 issues in the upstream bug tracker) and the With that reasoning apt should not be used by anything either as our upstream bug tracker has more than twice the amount of open bugs. ;) > I would therefore like to ask you to exclude googletest for the affected > architectures until either Google upstream or the maintainer of googletest > can be bothered to fix their software. > > I think I don't need to elaborate why not being able to built src:apt is > a bad thing on any architecture. I see how that can be inconvenient, but we had that situation before with cmake and that got thankfully resolved, too. Our gtest-based testsuite isn't very big, but I would really like to avoid disabling them as once in a while they catch things we wouldn't have noticed otherwise (like botched optimizations do to a markup error on our side – powerpc) or break the world^Wport (like unaligned access in hashsum calcs – sparc). If that situation doesn't change for a while or gtest maintainers are really not helpful we can drop the B-D quickly as its already droppable via build-profiles (and yes, it will be handled before stretch, promise). So @googletest maintainers, please state what you can/want to do about it or not. Being a build-dependency of apt provides some benefits, but also carries a cost in that there basically is no distinction between release, non-release and unofficial port architectures. If you can't/won't pay that price that is fine, we (as in deity@l.d.o) just need to know and we will figure something out – I just want to ask first before we rush into evaluating and moving to other testing frameworks, which is time better spent on other bugs if we can help it… Beside, even if you decide not care that would still need to be expressed in the metadata, so reassign the bug as to be handled by you. Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature