On Mon, 02 Jan 2012 11:28:45 +0100 A Mennucc <mennucc1@debian.org> wrote: > hi, related to the pygame problem [1] is another question: > > will kfreebsd-* be a release architecture in wheezy? > > If yes -> > then portmidi has a release critical bug in it, it should Whether any particular arch is a release arch or not, merely because a particular package is not available for that arch does not mean that the package has an RC bug. If it claims to be available and then fails, that is different but a possible fix for such bugs is to not build the package on that architecture. Many packages are specific to individual architectures. The bugs would be in the reverse dependencies which require the package but are still trying to install on architectures where that package is not (or is no longer) available. e.g. there are plenty of packages which are i386 or amd64 only - those are inevitably missing on armel and mips etc. The only bugs would be if packages in armel or mips etc. depended on these packages. Wherever possible, packages must build on all release architectures but if the architecture itself does not support functionality required for the package (e.g. stuff that is specific to linux kernels) there is usually little point trying to reimplement that functionality in the userspace code. In general, metapackages and Arch:all packages are immune to this requirement - debcheck adds details to the relevant PTS pages but most instances are not a problem. > be removed from testing [2], and at the same time pygame > should be built w/o it ; The reverse dependencies would appear to need fixing. 0: By removing the reverse dependencies from architectures where the dependency is not available or 1: By patching the reverse dependencies to use something else or not implement that functionality where it does not exist. > The current situation is a mess, since 'portmidi' is in testing, but > there is no kfreebsd-* binary for it (as if "no") - whereas > python-pygame is not allowed in (as if "yes"). The current situation is that portmidi is waiting for it's reverse dependencies to catch up with the requirements of the new version. This is correct - portmidi cannot migrate until it's reverse dependencies are fixed. portmidi does not need to be removed from testing, it is satisfying the release criteria and the migration criteria (hence valid candidate) - what is broken are the reverse dependencies which still expect it to be available on architectures where it cannot actually build or function. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgptzxlh06agv.pgp
Description: PGP signature