Matt Zimmerman <[EMAIL PROTECTED]> wrote: > On Sun, May 25, 2003 at 07:37:10AM +1000, Herbert Xu wrote: >> >> How does this automate the arch-specific merges where conflicts arise? > > 1. unpack pristine kernel source > 2. apply Debian patch > 3. dry-run arch-specific patch > 4. if no conflicts, test and release, otherwise: > 5. apply arch-specific patch to pristine kernel source > 6. 3-way merge between pristine kernel source, Debian tree, and > arch-specific tree > 7. resolve marked conflicts by hand > > Obviously conflicts must be resolved manually, hence the "mostly" above. > This is relatively straightforward to do within a source package, given > direct access to the (separate) pristine kernel source and Debian patch.
But the pristine kernel source and the Debian patch are already available to the architecture maintainers: apt-get --tar-only source kernel-source-2.4.xx apt-get --diff-only source kernel-source-2.4.xx So I don't think having a kernel-patch-debian by itself is of any value to the merging process. It also doesn't solve the problem that a new kernel-patch-debian may break the building of old kernel-image packages. There is also the suggestion of a complete break down of all Debian changes should be made available. Unfortunately that is simply unmaintainable and unusable as the number of changes grows as the dependencies between the patches are complex. I think perhaps we could find a middle ground. We can keep kernel-source as it is with all the patches applied. In addition to that, we can have a kernel-patch-debian package which depends on the kernel-source of the same upstream version containing patches that will take the kernel-source to the following source trees: 1. The pristine upstream except for non-free removals. 2. All previous kernel-source revisions of that release. For example, kernel-patch-debian-2.4.20 will contain patches that will give you the kernel-source-2.4.20-[1-7] packages respectively. These patches will be presented in incremental form with wrapper scripts around them that will preserve compatibility with previous kernel-patch-debian packages of the same version. The per-architecture kernel images can then depend on kernel-patch-debian and use the wrapper script that is most appropriate at that particular time. If a new kernel-source/kernel-patch-debian pair of the same version is released then nothing will be broken as there will be a patch with the same name in kernel-patch-debian that takes you to exactly the same source tree used to build previous kernel-image packages. This approach has the following benefits: * The kernel-source binary contains all bug fixes as is. Guido raised a good point that if we separated the patches from the kernel-source, then users may miss out on the bug fixes. This is especially important in light of the current speed of upstream releases. * The pristine kernel-source is available in the binary archive. Many people have asked for this in the past and this makes it available in the form of a source tar ball plus a patch. * Per-arch kernel-image will no longer be made unbuildable by new kernel-source updates. This has always been a problem for those architectures using the main kernel-source archive. * The incremental patches should ease the merging process of those architectures that wish to incoporate Debian changes. * The incremental patches should also allow people to get only the updated kernel-patch packages if they wish. I'd like to hear from the architecture maintainers if this proposal poses any problems to them. Cheers, -- Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ ) Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt