Bug#219582: ITP: linux -- Linux 2.4 kernel
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...
Reply to: