[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: