Re: Maintaining kernel source in sarge
On Sun, May 25, 2003 at 08:12:00AM +1000, Herbert Xu wrote:
> Christoph Hellwig <hch@lst.de> wrote:
> >
> > Why can't Debian have just one tree for multiple architectures like
> > SuSE and RedHat (sometimes) do. Okay suse supports 'only' i386,
> > x86_64,ppc,ppc64,s390,s390x,ia64 but their kernel also has patches
> > for sparc,sparc64,mips and m68k although I can't guarantee that these
> > really work in the relased tree (but last time I visted their office
> > people were playing with those ports in their spare time).
>
> I don't think we can go all the way yet, but let's make a start. If
> the architecture maintainers send me patches which clearly don't affect
> other archs or otherwise cause build problems, I will merge them.
I found this thread only yesterday, it would be nice if Joey could summarize
again, I don't read d-d very often.
I think this is contracticting to what you said just a few messages earlier.
For 2.4.21 will there be a pristine kernel-source and seperate i386-patch or
not? It seems I am the m68k maintainer, and I am for the seperate patch
solution. Reading this thread, I think the m68k kernel-patch has to be
improved, but if you leave the kernel-source as it is now, this means I have
to diff linux-m68k against linux-i386 to generate my m68k diff. Then I have
to create the i386 diff from your kernel-source package (IIRC it does not
ship as a seperate patch, it is included when I unpack kernel-source), then
put those two diffs in the m68k kernel-patch package and hope they both
apply. I think creating the i386 diff, or the security-patches diff is your
job, not mine or of the maintainers of the other 10 arches. Especially since
you know much better which patches are security related, which are i386
specific, and which fix some stupid typo which you can not stand to read
anymore, but might break compatibility with all the other arches. Has this
been decided yet? Maybe even if you continue to pack everything into the
kernel-source package, you could create this security diff with every new
version just for us port maintainers so it will be easier for us to update
our kernel-patch packages? On the other hand it seems if I create the diff
the right way, it is becoming pretty small and you might be able to merge it
completely into your source, so you still want that?
Another thing that is unclear to me is the naming of the packages. I was
suprised to see so many different 2.4.20 packages exist for i386, and I
still have problems figuring out the differences between them, and the
related kernel-headers packages. Are there some rules for this? I don't care
much about the i386 package names (except for which to use on my own box),
and I think nobody minds the kernel-image-2.4.20-[amiga|atari|mac|*vme*]
names, but there seems to be some discrepancy about the kernel-headers. m68k
used to have: kernel-headers-2.4.9_2.4.9-2_m68k.deb (which BTW is obsolete,
together with all 2.4.x < 2.4.20). I changed that for the latest version to:
kernel-headers-2.4.20-m68k_2.4.20-1_m68k.deb since I did not want to
conflict with other kernel-headers which might exist for m68k. Is this
good/bad/doesn't matter and what is the recommended naming? It seems every
maintainer does it as she likes (some random packages):
arch-in-name_all.deb:
kernel-headers-2.4.20-sparc_26.potato.1_all.deb
arch-in-name_arch.deb:
kernel-headers-2.4.18-686_2.4.18-5_i386.deb
something-in-name_arch.deb:
kernel-headers-2.4.20-1-wildfire_2.4.20-6_alpha.deb
nothing-in-name_arch.deb:
kernel-headers-2.4.18_2.4.18-5_i386.deb
something-and-arch-in-name_arch.deb:
kernel-headers-2.4.20-1-686_2.4.20-7_i386.deb
Same for kernel-patch, but most of them are arch-in-name_all.deb.
Any guidelines on this or are we free to do as we like?
Fortunately there are no kernel-modules for m68k (that I know of), so I am
ignoring the major part of this thread.
Christian
Reply to: