On Fri, Nov 07, 2003 at 04:22:27PM -0500, Daniel Jacobowitz wrote: > Then how do you suggest maintaining a kernel 2.4.20 for one > architecture and a 2.4.22 for another architecture, when you can't even > test on either of them? And how do you expect to ever upgrade the > result without duplicating all the work done by all the existing kernel > package maintainers for all Debian architectures? > > This doesn't even make any sense. Might as well just set Architecture: > i386.
Situation when 2.4.22 does not work on architecture in question is a *bug*, plain and simple. Same as when 2.3.2 doesn't work on the same architecture. And correct way to deal with that is to report these bugs upstream and/or submit patches fixing them. BTW, is there any reason why kernel-patch-2.4.22-powerpc-2.4.22 exists? I'm looking through the splitup of that patch right now (and by $DEITY, it should've been split from the very beginning - what with it being pulled from ppc BK tree). There we have: 1) sungem patch 2) minor cleanup in ne2k-pci (platform-independent) 3) extra PCI ID in tg3 table. 4) change in drivers/sound/config.in (affects only powerpc builds) 5) usb-ohci - more conservative alignment. 6) aty128fb.c ifdef changes (affects only powerpc builds) 7) additional constants defined in radeon.h (none of them used in #ifdef/#ifndef/defined()) 8) drivers/video/Config.in change (affects only powerpc builds) 9) patches in arch/ppc and include/asm-ppc (affects only powerpc builds) 10) extra PCI IDs in pci_ids.h Out of these, ##2--4,6--10 can and should be in the common tree. #5 either should be arch-conditional (it's a couple of lines) or it should be simply applied on all platforms - depends on the reasons why it exists. #1 needs testing on sparc. Until it gets such, make it arch-conditional. And there goes the bleeding package. I mean, WTF? We don't have separate source packages for gcc-3.3/powerpc or gcc-3.3/alpha. We certainly *do* have patches unique to these platforms in there. And gcc, glibc and binutils are autobuilt. I sincerely hope that it doesn't imply "Architecture: i386" on those. Sigh...