Re: creating kernel udebs from kernel-source
Andres Salomon wrote:
> > This "Hooray, it compiles!" approach is unlikly to ever produce an
> > useful kenrel for architectures not maintained in mainline.
> I fail to see why not. How is it we can keep patches in arch-specific
> k-i packages, but keeping them in k-s won't work?
As already mentioned on IRC, I misunderstood some parts of your mail
an thought the idea was to abolish the kernel-source Package as well.
> You mentioned the fact
> that mips upstream is essentially a fork of Linus' tree; I suspect this is
> the case simply because they wait so long before resynchs,
The situation improved significantly for 2.6, however, there's still
need to mips-specific patches not in mainline.
> and when they
> do attempt to synch, they send large patches that Linus rejects.
Rather: They send large patches and Linus accepts. :-)
> If we're
> going to be maintaining and dealing w/ these patches anyway, why not just
> feed split out changes to Linus?
The easy ones are probably already sent, the hard ones have usually
a reason why they shouldn't go upstream as is. The stuff in the
middle needs some polishing like updates to more modern kernel
Of course, I don't oppose to send patches to kernel.org from k-s, but I
think it is more efficient to do this between linux-mips.org and
> It makes everyone's life easier; for the
> next kernel revision, the patch has been merged; mips upstream has less of
> a diff between Linus' tree and theirs; and Linus and co. aren't being
> bombarded w/ 2 meg patches.
2 MB is the overall diff size, sending it as a single patch would
clearly be insane. :-)
> As I mentioned above, that's just a goal to work towards. It may work, it
> may not. However, a bunch of k-i packages consist mostly of
> debian packaging and config files. There's no reason to have those as
For some architectures it clearly makes sense to drop those packages.
I just want to keep them for architectures where they are more useful.