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

Re: Dropping 2.4 hppa kernel-image packages



On Wed, Jan 12, 2005 at 10:37:10PM +0100, Thibaut VARENE wrote:
> I've been discussing lately on #d-kernel about the fate of 2.4 hppa kernel
> packages. Here is a brief summary of the issue:

> I received a bugreport (#289590) because 2.4.27 package FTBFS, and that's
> the result of:
> 1) a (imho) very invasive and massive Debian patchset that conflicts with
> 2) a huge, dirty and no longer maintained parisc 2.4 diff to the pristine
> kernel.

> In other words, I'm up to the point where it begins to be unreasonably
> complicated to maintain a 2.4 Debian package because OTOH we (parisc-linux
> kernel hackers) no longer maintain our 2.4 repository and OTOH the 2.4
> parisc port has always been nothing but a big hack to the 2.4 pristine
> source. Indeed, we never merged upstream because in order to get things
> somehow working we've touched many arch-indep files in a dirty and hacky
> way, making the changes unsuitable for upstream inclusion.

> Since the parisc-linux diff is taken against a snapshot of the pristine
> kernel tree. Tailoring it to make it apply fine on a Debian patched kernel
> is quite a PITA (the parisc patch is roughly 800k).

> Now comes the question of the meaning of having a debian package for a no
> longer supported _UPSTREAM_ kernel. We (parisc hackers) put all our
> efforts in 2.6 and strongly advise everyone to use 2.6. We are no longer
> maintaining 2.4 (last update to our tree is several months old, and 2.4.28
> merge is not on the todo list).

> I've been told by Joey Hess that 2.6 support for d-i is mostly there, so
> I'd like to know what would eventually raise against dropping 2.4 package
> in the very near future (ie: before sarge releases).

If the hppa 2.6 kernels were included in the last d-i release candidate and
there are successful install reports with that version, I think it's
reasonable to consider dropping 2.4 kernels if they're really this difficult
to support.

If 2.6 was not actually used on this architecture in RC2, then someone
should have realized that 2.4 was unsupportable three months ago, *before*
RC2 was released.  Going straight from no 2.6 support in the installer to
using it as the only kernel we're shipping in the space of a single release
candidate cycle is really not an option, there simply aren't enough
safeguards against a change like this derailing the release planning
process.

-- 
Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature


Reply to: