Re: Maintaining kernel source in sarge
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
Reply to: