Re: Best practices for kernel patches?
herbert@gondor.apana.org.au (Herbert Xu) writes:
> Kernel-patch packages
> were originally devised to allow us to maintain kernel packages for
> multiple architectures as the upstream kernel doesn't work out of the
> box on all of them.
Of course, that hasn't worked as planned, for at least two reasons.
For hppa and ia64, the fact that the canonical kernel-source-<version>
packages have i386-centric and/or Debian-centric patches that conflict with
patch bundles for other architectures means they aren't particularly suitable.
It would work a lot better if we structured things so that each architecture
could provide diffs against pristine upstream Linus source and not something
which has already had patches applied. It's possible to reconstitute patches
so that they don't conflict, but the second or third time I had to debug a
failure on ia64 that resulted from a patch Herbert applied for a problem on
i386 that makes things worse on ia64, I grew weary.
Secondly, I got burned trying to deliver kernel-patch-<version>-ia64 packages
against kernel-source-<version> because you don't leave the source packages
around very long. Architectures that aren't merged with Linus fully are
usually a rev or three behind, so having the, say, 2.4.7 kernel source package
removed from the archive because 2.4.9 is out for at least i386 means things
were broken for ia64, et al, pretty regularly. I got uppity with James about
removing kernel-source-<version> packages when there were other packages that
build depended on them, but after talking it became clear that it really was
up to the registered maintainer of the package to decide how long they should
live and when they should be removed... and I needed to insulate myself from
frustration some other way.
So, what I do now is deliver kerenl-image-<version>-<arch> source packages that
emit a variety of suitable binary packages, and each contain everything needed
for a successful build. This works fine, but is of course wasteful of archive
space since we probably end up with many more copies of the source tree for
any given kernel version in the archive at one time than we should really need.
I haven't raised this before as a problem area because it isn't really a bug
in any existing packages, rather it's a structural issue with the way we
deliver and present kernel source and derived binaries to our users, and I
suspect it will take some work to improve. Also, it clearly seemed like
something we should leave alone for woody, and address for woody+1.
As the owner of the kernel image packages in Debian for two architectures at
the moment (hppa and ia64), I'd be pleased to collaborate on improvements
going forward...
Bdale
Reply to: