Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Fri, Nov 07, 2003 at 10:20:25PM +0000, viro@parcelfarce.linux.theplanet.co.uk 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
Reply to: