Steve Langasek wrote: >> So what about other architectures?? Should I guess that it will not run >> on ia64 or the s390? Or is it ok to have potentially broken binaries >> until someone complains? > > Ideally, broken packages would be detected at build time. Otherwise, in the > absence of feedback telling us that the package is broken, we shouldn't > assume that it's broken either. But a known-unusable binary package needs > to be addressed for the release.
Ideally, it would have been better to know this a few months ago. What would be even better if we could tag RC bugs against specific architectures so a package that eventually will work on all but doesn't yet could be 1. built in Sid by all arch ALL the time, for testing, etc... 2. a given binary doesn't progress to testing because due to RC bug against that package's architecture. So if there is a potential fix for the problem, the package is built and people can easily check if the program now works on the broken arch. As it is right now, packages have to be built by hand on the broken arch which can be a hustle for people that don't want to install all of the dev packages just to test if a binary runs and report bugs (ie. the non-developers) - Adam PS. Please don't remove this package from testing even though AMD is broken there. I'll try to get either the fix or exclude amd64 from build architectures... I guess I could use a relative's amd64 to see what the problem is and if mysql-admin (another package with some shared connection code) even works. And that one may be affected as well even though upstream says otherwise. I think they may be using 32-bit app on Amd64 32bit/64-bit like Suse and stating it works........ blah... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
