On Sun, May 25, 2003 at 08:12:00AM +1000, Herbert Xu wrote: > Christoph Hellwig <[EMAIL PROTECTED]> 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