Re: Bug#361024: note on 2.4 is deprecated
On Thu, Apr 13, 2006 at 03:26:10PM -0700, Steve Langasek wrote: Rather, I think it would mean people would be upset about 2.4 being dropped with little official notice -- but yes, this should be announced sooner rather than later. The announcement of the obscolecence of the 2.4 kernels by the kernel team a few weeks ago is already a good step into this direction. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: note on 2.4 is deprecated
Manoj Srivastava wrote: On 13 Apr 2006, Bastian Blank wrote: On Thu, Apr 13, 2006 at 10:28:56AM -0500, Manoj Srivastava wrote: That is stretching it. The third component of a version is hardly a major revision. Why? Component in a version are major.minor.sub. Now, given that Linux 1.0 was ages ago, one could conced that the versioning is Epoch.Major.Minor Upstream declared 2.6 a constant for the time being, so the third component remains the only one to make a version distinction. But claiming that 2.5.16 is majorly different from 2.5.15 when it comews to support is a facile argument that most people are not gonna buy. We already saw that for 2.6.12 - .13. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: note on 2.4 is deprecated
dann frazier wrote: If for no other reason, upstream release process changes will likely make this much more difficult. As I'm sure you know, 2.6 is being actively developed indefinitely, as opposed to the previous method of branching off and stabalising a development tree. Since there is no existing plan for a 2.8, 2.4 would need to be maintained indefinitely to continue a major + major-1 support model. Sure, I think there's something to the point someone else made in this thread that each 2.6.x is essentially a new major version now. Although clearly not quite the same as before. -- see shy jo signature.asc Description: Digital signature
Re: note on 2.4 is deprecated
On 9 Apr 2006, Warren Turkal wrote: On Sunday 09 April 2006 12:14, Joey Hess wrote: - Debian's userland has *always* supported at least the previous major kernel version, and most often the previous two, or sometimes I think, three major kernel versions. I think it could be easily argued that the last three major revisions of the kernel or 2.6.16, 2.6.15, and 2.6.14. That is stretching it. The third component of a version is hardly a major revision. manoj -- A free society is one where it is safe to be unpopular. Adlai Stevenson Manoj Srivastava [EMAIL PROTECTED]http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: note on 2.4 is deprecated
On Thu, Apr 13, 2006 at 10:28:56AM -0500, Manoj Srivastava wrote: That is stretching it. The third component of a version is hardly a major revision. Why? Bastian -- If I can have honesty, it's easier to overlook mistakes. -- Kirk, Space Seed, stardate 3141.9 signature.asc Description: Digital signature
Re: note on 2.4 is deprecated
* Joey Hess: - Debian's userland has *always* supported at least the previous major kernel version, and most often the previous two, or sometimes I think, three major kernel versions. This isn't a real argument, IMHO, because upstream no longer releases major kernel versions. OTOH, dropping support for 2.4 kernels at this stage feels wrong. (Even though I'd rather do it ASAP so that we can compile Berkeley DB with POSIX threading. 8-) It might make sense to declare etch the latest release which supports 2.4, though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361024: note on 2.4 is deprecated
On Thu, Apr 13, 2006 at 09:52:42PM +0200, Florian Weimer wrote: * Joey Hess: - Debian's userland has *always* supported at least the previous major kernel version, and most often the previous two, or sometimes I think, three major kernel versions. This isn't a real argument, IMHO, because upstream no longer releases major kernel versions. OTOH, dropping support for 2.4 kernels at this stage feels wrong. (Even though I'd rather do it ASAP so that we can compile Berkeley DB with POSIX threading. 8-) It might make sense to declare etch the latest release which supports 2.4, though. I think etch should support 2.4 in the sense of upgrade support only; i.e., it should support 2.4 because we need to be able to install etch on systems running sarge 2.4 kernels, not because we'll provide support for 2.4 in etch. This AFAIK will satisfy Joey's need for interim 2.4 compatibility, while making it clear that the upgrade to 2.6 needs to happen before the etch+1 release. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#361024: note on 2.4 is deprecated
On Thursday 13 April 2006 22:59, Steve Langasek wrote: I think etch should support 2.4 in the sense of upgrade support only; i.e., it should support 2.4 because we need to be able to install etch on systems running sarge 2.4 kernels, not because we'll provide support for 2.4 in etch. What about (sub)arches that currently do not yet support installing 2.6? If 2.4 is really going to be dropped for Etch except for upgrade purposes, I'd very much like to see a formal (release) policy statement saying so. If 2.4 kernels are really abandoned, it will mean that we (d-i) could (should even) start cleaning out 2.4 related code and prod lagging architectures into more speed where it comes to switching to 2.6. Delaying a formal decision much longer will probably mean we'll be stuck with 2.4 whether we like it or not. pgpYvdjQO2ADF.pgp Description: PGP signature
Re: note on 2.4 is deprecated
On 13 Apr 2006, Bastian Blank wrote: On Thu, Apr 13, 2006 at 10:28:56AM -0500, Manoj Srivastava wrote: That is stretching it. The third component of a version is hardly a major revision. Why? Component in a version are major.minor.sub. Now, given that Linux 1.0 was ages ago, one could conced that the versioning is Epoch.Major.Minor But claiming that 2.5.16 is majorly different from 2.5.15 when it comews to support is a facile argument that most people are not gonna buy. manoj -- It is better for civilization to be going down the drain than to be coming up it. -- Henry Allen Manoj Srivastava [EMAIL PROTECTED]http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361024: note on 2.4 is deprecated
On Thu, Apr 13, 2006 at 11:20:38PM +0200, Frans Pop wrote: On Thursday 13 April 2006 22:59, Steve Langasek wrote: I think etch should support 2.4 in the sense of upgrade support only; i.e., it should support 2.4 because we need to be able to install etch on systems running sarge 2.4 kernels, not because we'll provide support for 2.4 in etch. What about (sub)arches that currently do not yet support installing 2.6? These subarches would have to either get ported to 2.6, or not be supported for the release. Do you see any other options here? If 2.4 is really going to be dropped for Etch except for upgrade purposes, I'd very much like to see a formal (release) policy statement saying so. Well, then I think this will have to go in the next release update, unless someone steps forward to maintain 2.4 for etch before then. I think that's pretty unlikely, since the current kernel team appears unwilling to support 2.4, and any such support needs to include security support (or else it's not worth including it in stable). With no upstream security support for 2.4, it seems unlikely that anyone would consider that a worthwhile trade-off, and I don't think the security team is going to be willing to be left holding the bag. If 2.4 kernels are really abandoned, it will mean that we (d-i) could (should even) start cleaning out 2.4 related code and prod lagging architectures into more speed where it comes to switching to 2.6. Delaying a formal decision much longer will probably mean we'll be stuck with 2.4 whether we like it or not. Rather, I think it would mean people would be upset about 2.4 being dropped with little official notice -- but yes, this should be announced sooner rather than later. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: note on 2.4 is deprecated
On Sun, Apr 09, 2006 at 02:14:58PM -0400, Joey Hess wrote: - Debian's userland has *always* supported at least the previous major kernel version, and most often the previous two, or sometimes I think, three major kernel versions. If for no other reason, upstream release process changes will likely make this much more difficult. As I'm sure you know, 2.6 is being actively developed indefinitely, as opposed to the previous method of branching off and stabalising a development tree. Since there is no existing plan for a 2.8, 2.4 would need to be maintained indefinitely to continue a major + major-1 support model. I of course agree with you that there's no reason to preclude user-built kernels; and we certainly need to maintain the upgrade path. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
note on 2.4 is deprecated
I just wanted to comment on the 2.4 is deprecated thing. Just because the kernel team is muttering[1] about not supporting the 2.4 kernel does not mean that Debian as a project has decided not to support users using their own versions of this kernel. As Steve notes in #361024, we have to support 2.4 anyway to support users upgrading from sarge. Some other good reasons for the project to continue to support 2.4 include: - There is still hardware that is only supported by various 2.4 kernels. For example, I have various arm boards and mips machines that are running Debian with, 2.4, non-debian kernels, which still work fine (until this bug). Dropping support for 2.4 will simply make this hardware useless, since Debian is the only reasonable distribution that runs on it, and since doing the work to make 2.6 run on it varies from far too much effort to nearly impossible (think binary 2.4 only kernel modules). - We can't all upgrade to 2.6 trivially. I have production machines that are colocated thousands of miles from me, and upgrading them to 2.6, while scheduled, involves a plane trip, and considerable expense. - Making debian unstable not work in a chroot on a stable machine that happens to be running 2.4 is not a good idea. Consider that Debian has a lot of machines running stable with 2.4 + chroots. Also, it would make remote cross-distribution debtakeovers of machines running some horrible ancient version of redhat difficult. - Debian's userland has *always* supported at least the previous major kernel version, and most often the previous two, or sometimes I think, three major kernel versions. PS, Petr Salinger's glibc test package fixes #361024 for me on my 2.4 machine. Unfortunatly, since that machine is responsible for the d-i i386 daily builds, which involve copying glibc into the d-i images, and since I do not want to ship d-i images containing an unofficial glibc, I've had to take those builds down until this is resolved in a glibc in unstable. Hope it's resolved soon.. -- see shy jo [1] Or at least some of them are, it's not clear to me if the d-d-a mail captured the consensus of the team. signature.asc Description: Digital signature
Re: note on 2.4 is deprecated
Not that my opinion means much, but... On Sunday 09 April 2006 12:14, Joey Hess wrote: *snip* - Debian's userland has *always* supported at least the previous major kernel version, and most often the previous two, or sometimes I think, three major kernel versions. I think it could be easily argued that the last three major revisions of the kernel are 2.6.16, 2.6.15, and 2.6.14. wt -- Warren Turkal Research Associate III/Systems Administrator Colorado State University, Fort Collins
