Re: creating kernel udebs from kernel-source
After speaking w/ ths on IRC, I should probably clarify a few things:
- When I talk about kernel-image packages, I'm referring to both source
packages actually named "kernel-image-*" (such as
kernel-image-2.6.8-i386), and kernel-patch-* packages that generate binary
kernel-image packages (such as kernel-patch-2.4.27-mips).
- Having all kernel-images generated from k-s is a goal; I realize it's
not immediately obtainable, given the current state of some of the kernel
archs.
- I'm not forcing this upon anyone; port maintainers can maintain images
however they see fit, because no one has any intentions of stepping in if
they throw their hands up and quit. However, I do believe this will make
everyones lives easier. k-s contains split up patches (in many cases w/
bk changeset references and other such comments) that make forward porting
to new kernels much easier. They're also easier to feed Linus; instead of
a massive patch w/ a bunch of changes, small patches can be sent.
On Mon, 29
Nov 2004 22:54:32 +0100, Thiemo Seufer wrote:
> 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? 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, and when they
do attempt to synch, they send large patches that Linus rejects. If we're
going to be maintaining and dealing w/ these patches anyway, why not just
feed split out changes to Linus? 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.
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.
>> 3) Simplify packaging. Dump the kernel-tree-X crap, etc. The cons of
>> this are that one will no longer be allowed to build against an older,
>> known-working k-s.
>
> Which means those architectures will still need a source package they
> can build-depend on, generated from the -image source. This is a minimal
> workload reduction for the kernel team but an increase for the security
> team.
>
I'm not sure I understand this. For a debian release, we'll still need to
pick a kernel and get all archs in shape for it (I believe for sarge, the
kernel is 2.4.27 and 2.6.8, w/ the exception of m68k, which is going w/
2.2.x?). That shouldn't be any additional work for the security team,
although the testing security team may have to deal w/ multiple kernels in
testing. OTOH, the security teams (both stable and testing) would only
have to deal w/ patching a single k-s package; all other archs would be
autobuilt, and thus made easier to fix. So, if anything, I think it would
be less work for each security team. And, there would probably be an
increase in effort required from the kernel team for each new kernel
release (since all archs will probably have to be worked on in order to
get a kernel into testing); however, in the long run, it will probably
even out, as its work that port maintainers would've had to do sooner or
later, as they update their arch packages for the latest target kernel.
Reply to: