On Sun, 25 May 2003 04:18, Bernd Eckenfels wrote: > On Sat, May 24, 2003 at 07:55:08PM +0200, Christoph Hellwig wrote: > > Some m68k architectures might be a hard, I agree. But having a package > > that works on as many machines as possible would be very cool. > > well, I there is a shared debian-kernel cvs then all architecture > maintainers can commit, and the package can be build for those who are > ready. This might generate a autobuilder and testing-transition problem :(
The problem here is when architecture specific patches require patches to core code. If we have a single kernel source tree that everyone commits to then it will be changing daily, it will be difficult to determine what source was used to compile a particular kernel (and getting two kernels compiled from the same source will be a neat trick). I think that the thing to do is to have a base kernel source package that is the standard Linus tree plus fixes that are really important. That means security fixes, fixes to file systems to fix data-loss issues, etc. The VM fix for 2.4.20 which stops machines with 4G of RAM from choking under load would be a border-line case. Then patches that strictly affect one architecture will be separate, patches that are only really needed for one architecture (EG JFFS2 patches may be required for embedded devices but for most machines - including all Alpha's there would be no need for it) would be kept separate. Also for the architecture-specific patches we should avoid the temptation to merge in other patches. When people merge in patches for things such as XFS into more generic kernel patches (as SuSe appears to do) it makes things very painful for anyone who wants to extract things and use a sub-set of the patches. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page