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

Reply via email to