Re: Maintaining kernel source in sarge
Matt Zimmerman <mdz@debian.org> 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~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Reply to: