[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: kernel packages cleanup



On Tue, Mar 23, 2004 at 08:27:13PM +0100, Adrian Bunk wrote:
> On Tue, Mar 23, 2004 at 05:23:56PM +0100, Matthias Urlichs wrote:
> > Hi, Stephen R Marenka wrote:
> > > On Mon, Mar 22, 2004 at 07:33:59PM +0100, Martin Schulze wrote:
> > > 
> > >> m68k     --> I heard there may be problems with 2.4 *sigh*
> > > 
> > > The amiga port works with 2.4. The mac port doesn't, but people are
> > > actively working on it.
> > 
> > 2.4 may never support Macs, but 2.6 starts to look reasonably good on them.
> 
> Is there any ETA when there might be a good support in 2.6?

When it's ready. You can't use the keyboard yet I believe.

> > It probably won't be ready for Sarge, but d-i runs on 2.2 (I installed one
> > of my machines with it, last week) so we can always drop 2.2 support later.
> 
> If Debian 3.1r0 ships with kernel 2.2 you can't drop it in later point 
> releases.

We can drop it in sarge+.

> Depending on the release plan and the ETA for a working 2.6 on Macs it 
> might perhaps be possible to include an installer without support for 
> Macs in Debian 3.1r0 and add support for them in later point releases?

I just spent two months adding 2.2 and m68k support to d-i. I'd be a bit 
upset if we didn't release with any 2.2 kernels because it's 
aesthetically pleasing.

> You'd still be able to install Debian 3.0 and upgrade to Debian 3.1.

I volunteered to write the d-i support so that I didn't have to mess
with boot-floppies.

> A bigger problem might be sparc32...
> 
> > Anyway, for purposes of security updates, part of the problem seems to be
> > that m68k compilation is somewhat slow. To fix that, we can either accept
> > that $SLOW_ARCH's security uzpdates will be late, or cross-compile the
> > kernel on $FAST_ARCH.
> 
> No, the main problem for the security team is the manual work required.
> 
> Tracking three kernel trees (2.2, 2.4 and 2.6) would mean to collect
> information on security-related bugs, fix them in the sources, recompile
> all kernel images, test them and write advisories for three different
> trees, and this would effectively require 50% more work than supporting
> only 2.4 and 2.6. Since the kernel requires relatively many security
> fixes this is a serious amount of extra work.

Well I should think it would help quite a bit if we only have m68k and 
sparc32 2.2 kernels, instead of all the archs.

I'd be happy to volunteer to do whatever extra work is necessary to keep
2.2 m68k kernels in sarge. Since, I'm running three buildds with 2.2
kernels, it's inline with the work I'm already doing.

-- 
Stephen R. Marenka     If life's not fun, you're not doing it right!
<stephen@marenka.net>

Attachment: signature.asc
Description: Digital signature


Reply to: