"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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]