Re: Severity of architecture-dependent bugs

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

"Shaun Jackman" <sjackman@gmail.com> writes:

> A grave bug has been file against a package I maintain pointing out
> that the package does not work on AMD64 and in fact never has, even
> though it builds on AMD64. Since it turns out this package has never
> worked on AMD64, this bug is not a regression, but the status-quo.
> Should such a bug be grave, or merely important?
>
> Thanks,
> Shaun

As announced it will official be grave in ~2 weeks so lets not play
silly games about severity till then and instead consider some options:

1) stop building the package on amd64.

   Only do that if the package is not usefull for amd64 or fixing it
   to work is beyond reason. If you intend to get it working on amd64
   at some point (in the not to far future) then excluding amd64 just
   creates unneccessary work and will delay getting amd64 back in.

2) add a test target in debian/rules and call that during build

   You should be able to wip something up that will detect the current
   brokenness on amd64 and then fail the build itself. This will be a
   FTBFS (Failed-To-Build-From-Source) bug which has, for you, better
   rules about RC level. FTBFS is only RC if a previous version of the
   package did build. And since there is no official build and not
   even a working inofficial one this can be savely set to important
   only.

   This also a secondary effect for etch. Since there is no old
   version in etch for amd64 the missing deb in sid won't stop it from
   migrating. But as soon as you get a functional deb it will go right
   in, hopefully before etch freezes.

MfG
        Goswin