On Fri, Nov 07, 2003 at 10:20:25PM +0000, [EMAIL PROTECTED] wrote: > 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?
Nowadays? No particular reason, but when I maintained it I simply tracked the PPC BK tree. Lately, it's been a nice small patch, and I didn't have a chance to examine it (part of why I gave up the package). It used to be more like 100K gzipped, around 2.4.14 or so. > 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: It's a diff between two different lines of development, one of which gets periodically merged into the other. Splitting it by csets wouldn't give you anything useful, because you'd get a few small patches for changes since the last merge, and one patch representing the merge cset. It's a hard or impossible problem to preserve cset boundaries across such a merge. So, no, there is no easy way to split it. Especially, as I said, when the package used to be a whole lot larger :) I don't have time to merge-monkey for that tree, and it's not my business to, since the maintainers do it quite well overall. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
