Re: creating kernel udebs from kernel-source

[Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>]

Andres Salomon wrote:
[snip]
> > 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
interfaces.

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
kernel.org.

> 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
> separate.

For some architectures it clearly makes sense to drop those packages.
I just want to keep them for architectures where they are more useful.


Thiemo