Kernel patches and kernel-package 3.40

[Nikita Schmidt <cetus@snowball.ucd.ie>]

Hi,

After a closer look I got some questions about the proposed way of handling
kernel patches.

First, the package file names for architecture specific patches, headers
etc. look as if they were built from a single source:

>   kernel-patch-<version>_<version>_i386.deb  ; i386 specific patches, if any
>   kernel-patch-<version>_<version>_sparc.deb ; sparc specific patches, if any
>   kernel-patch-<version>_<version>_m68k.deb  ; m68k specific patches, if any

I mean that there is no standard way to guess the source package name
from a binary package name (unless all binaries are built from the same
source package).  Is the naming of each architecture-specific kernel-patch
source package left to the discretion of its maintainer or should a policy
decision be made?

Second, I suppose the second <version> in the package name does not have
to be related to the first one (the kernel version) like it is with the
kernel-source package, right?  It's just an upstream version and Debian
revision of the patch itself, so it will look like
	kernel-patch-2.0.30_0.2-2_alpha.deb
for alpha-patches-2.0.30-0.2.

Third,
>         The kernel-patch versions all depend on the generic source
>    kernel-source-<version>_<version>_all.deb, and all unpack into
>    /usr/src/kernel-patches/<architecture>/patch_<version>

Why should they?  The idea of kernel-package is to make it possible to
build any kernel from the original sources.  I don't see any reason why
patches can only be applied to a debianised source.  What if a port
maintainer wants to issue patches for a kernel version that does not
have the corresponding kernel-source package?

Fourth, currently the kernel-source packages contain patched sources
rather than original ones.  Should it be reported as bug now?

Thanks

	Nikita


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .