Re: Too many kernels in unstable
Peter S Galbraith wrote: Perhaps the last two kernels of the stable tree(s) is good. We have more kernels now because 2.0.X didn't die after 2.2.X was released. Doesn't that argue that 2.2.X wasn't ready? This could also be caused by the fact that someone, though he might be tempted to upgrade his kernel (e.g. to 2.0.38), does not want to upgrade all the other required programs (modutils, pppd, etc. etc.) This may be true especially for server systems - I'd be very hesitating to upgrade anything which isn't broken as is. Question is off course if you'd be willing to reboot your server to upgrade it's kernel anyway (though the latest to 2.0 kernels are probably worth it- if you can afford to be down for a few minutes). Also, I think there should always be a 2.0 series kernel available, just because they're usually smaller - it will be of good use on a low end system (i[3|4]86, 8 mb ram). --- Filip Van Raemdonck [EMAIL PROTECTED] member of the fibo-systeam http://fibo.hogent.be | http://fibolite.hogent.be ---
Re: Too many kernels in unstable
Roland Rosenfeld [EMAIL PROTECTED] wrote:
Maybe I don't see all the problems, but why don't we name the packages
kernel-{doc,headers,image,source}-2.0 2.0.38-debianrevision
kernel-{doc,headers,image,source}-2.2 2.2.12-debianrevision
This stops people from having multiple versions of 2.? kernels installed.
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Too many kernels in unstable
Herbert Xu [EMAIL PROTECTED] wrote:
Maybe I don't see all the problems, but why don't we name the packages
kernel-{doc,headers,image,source}-2.0 2.0.38-debianrevision
kernel-{doc,headers,image,source}-2.2 2.2.12-debianrevision
This stops people from having multiple versions of 2.? kernels installed.
Ooops, you're right. Please forget my above proposal. I still hate
this package name inflation, but there seems to be no way around it :-(
Tscho
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Re: Too many kernels in unstable
On Sun, 19 Sep 1999, Roland Rosenfeld wrote:
which would reduce the effort of the ftp maintainer and speed up
upgrading our ftp archive from 2.2.12 to 2.2.13. The dependencies
between the kernels and the kernel depending modules could be realized
using versioned dependencies, couldn't they?
Maybe we should add an unstable kernel to the stable versions above:
kernel-{doc,headers,image,source}-2.3 2.3.18-debianrevision
The problem is that sometimes and for some architectures the 'stable'
2.2 series kernels are less stable than, say, 2.1's, or for some
architectures 2.2.x is stable, for others, 2.2.y... so older versions
shouldn't be removed from the distribution too easily.
greetings
endre
--
..all in all it's just another rule in the firewall.
/Ping Flood/
Re: Too many kernels in unstable
On Mon, 20 Sep 1999, Hirling Endre wrote:
endreOn Sun, 19 Sep 1999, Roland Rosenfeld wrote:
endre
endre which would reduce the effort of the ftp maintainer and speed up
endre upgrading our ftp archive from 2.2.12 to 2.2.13. The dependencies
endre between the kernels and the kernel depending modules could be realized
endre using versioned dependencies, couldn't they?
endre
endre Maybe we should add an unstable kernel to the stable versions above:
endre
endre kernel-{doc,headers,image,source}-2.3 2.3.18-debianrevision
endre
endre
endreThe problem is that sometimes and for some architectures the 'stable'
endre2.2 series kernels are less stable than, say, 2.1's, or for some
endrearchitectures 2.2.x is stable, for others, 2.2.y... so older versions
endreshouldn't be removed from the distribution too easily.
Some people have suggested providing a package, say 2.2, with all
the 2.2.x source patches. (I didn't look at the size, but the patches are
sometimes small and sometimes 1.5 MB). It is not too inconvenient to
apply the patches to get to a specific kernel, and the source size is not
too big. I never use the debian source packages; there are probably
additional technical issues.
John Lapeyre [EMAIL PROTECTED]
Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Re: Too many kernels in unstable
On Mon, 20 Sep 1999, John Lapeyre wrote: Some people have suggested providing a package, say 2.2, with all the 2.2.x source patches. (I didn't look at the size, but the patches are sometimes small and sometimes 1.5 MB). It is not too inconvenient to apply the patches to get to a specific kernel, and the source size is not too big. I never use the debian source packages; there are probably additional technical issues. Not a bad idea, it can even be supported at the configure step if it asks for the kernel version and then applies the appropriate patches to the original tree. You can then include the last known stable version from every series and the patches that came out since. greetings endre -- ..all in all it's just another rule in the firewall. /Ping Flood/
Re: Too many kernels in unstable
On Fri, 17 Sep 1999, Edward Betts wrote:
My suggestion would be:
kernel-{doc,headers,image,source}-2.0.38
kernel-{doc,headers,image,source}-2.2.12
Can anybody provide arguements against just having two kernels?
Maybe I don't see all the problems, but why don't we name the packages
kernel-{doc,headers,image,source}-2.0 2.0.38-debianrevision
kernel-{doc,headers,image,source}-2.2 2.2.12-debianrevision
which would reduce the effort of the ftp maintainer and speed up
upgrading our ftp archive from 2.2.12 to 2.2.13. The dependencies
between the kernels and the kernel depending modules could be realized
using versioned dependencies, couldn't they?
Maybe we should add an unstable kernel to the stable versions above:
kernel-{doc,headers,image,source}-2.3 2.3.18-debianrevision
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Re: Too many kernels in unstable
On Fri, 17 Sep 1999, Brian Mays wrote: Perhaps we should keep the last two versions of each branch? In this case, 2.0.35, 2.0.36, 2.2.10, and 2.2.12 (which is in Incoming). I don't know. Let's see whether anyone objects to just keeping two versions around. That seems reasonable. Once the 2.0.x kernels finally are obsoleted, there may be three 2.2.x kernels. Bjorn Brill [EMAIL PROTECTED] Frankfurt am Main, Germany
Re: Too many kernels in unstable
On Fri, Sep 17, 1999 at 07:25:15PM +0100, Edward Betts wrote:
Can't we keep the number down to something more manageable, say 4 at
most?
We now have:
kernel-{doc,headers,image,source}-2.0.35
kernel-{doc,headers,image,source}-2.0.36
kernel-{doc,headers,image,source}-2.2.1
kernel-{doc,headers,image,source}-2.2.5
kernel-{doc,headers,image,source}-2.2.7
kernel-{doc,headers,image,source}-2.2.9
kernel-{doc,headers,image,source}-2.2.10
kernel-{doc,headers,image,source}-2.2.12
My suggestion would be:
kernel-{doc,headers,image,source}-2.0.38
kernel-{doc,headers,image,source}-2.2.12
Can anybody provide arguements against just having two kernels?
Unless someone else can demonstrate a need for 2.0.36 that will affect a
number of people, I think 2.0.38 alone would be reasonable.
I think someone said they needed 2.2.7, which kinda needs a few patches
from 2.2.8 and 2.2.10 to work as expected (2.2.7 needed a security patch
and sound was completely broken IIRC..)
I'm not objectionable to a 2.3.x, but I really don't think it's a good
idea.
--
Joseph Carter [EMAIL PROTECTED] Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77 8E E2 29 96 C9 44 5F BE
--
But modifying dpkg is infeasible, and we've agreed to, among other things,
keep the needs of our users at the forefront of our minds. And from a
user's perspective, something that keeps the system tidy in the normal
case, and works *now*, is much better than idealistic fantasies like a
working dpkg.
-- Manoj Srivastava
pgpgQvj5FZxDM.pgp
Description: PGP signature
Re: Too many kernels in unstable
I'm not objectionable to a 2.3.x, but I really don't think it's a good idea. Hey...my Debian Ultra SPARC system *loves* the 2.3.x kernel a heck of a lot better than the 2.2.x strain. I think that for unstable a version (or 2 depending of needs) of each kernel tree would be nice...but for stable an unstable kernel probably wouldn't be best (unless it's needed for some specific reason)...mainly because by the time the stable version comes out of frozen it will be outdated. :) Ivan -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ivan E. Moore II Rev. Krusty http://www.tdyc.com [EMAIL PROTECTED] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Imagination is more important than knowledge - Albert Einstein -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- GPG KeyID=0E1A75E3 GPG Fingerprint=3291 F65F 01C9 A4EC DD46 C6AB FBBC D7FF 0E1A 75E3 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Too many kernels in unstable
Once 2.2.12 makes it out of Incoming, we will have 8 kernel versions in the unstable distribution? Do we REALLY need to provide that many versions of the kernel?? I hate to complain, but every time a new version of the PCMCIA modules is released, I have to build a set of packages for EACH of these kernels. It's starting to become a real pain in the ass. Can't we keep the number down to something more manageable, say 4 at most? Brian
Re: Too many kernels in unstable
[EMAIL PROTECTED] (Brian Mays) writes: Once 2.2.12 makes it out of Incoming, we will have 8 kernel versions in the unstable distribution? Do we REALLY need to provide that many versions of the kernel?? What about just keeping the last 2.0.x and the last 2.2.x ? It's also a lot of space on the ftp site. Guy
Re: Too many kernels in unstable
[EMAIL PROTECTED] (Brian Mays) writes: Once 2.2.12 makes it out of Incoming, we will have 8 kernel versions in the unstable distribution? Do we REALLY need to provide that many versions of the kernel?? Guy == Guy Maor [EMAIL PROTECTED] writes: What about just keeping the last 2.0.x and the last 2.2.x ? That would be fine by me; however, some people might object because kernel improvements sometimes break things -- even in stable kernel branches. It is not so rare for someone to avoid upgrading to the next kernel version, because it breaks some obscure feature that he needs. Perhaps we should keep the last two versions of each branch? In this case, 2.0.35, 2.0.36, 2.2.10, and 2.2.12 (which is in Incoming). I don't know. Let's see whether anyone objects to just keeping two versions around. It's also a lot of space on the ftp site. It's a lot of space on my laptop too... (93M to be precise) Brian
Re: Too many kernels in unstable
Once 2.2.12 makes it out of Incoming, we will have 8 kernel versions in the unstable distribution? Do we REALLY need to provide that many versions of the kernel?? What about just keeping the last 2.0.x and the last 2.2.x ? It's also a lot of space on the ftp site. And maybe one from the unstable tree 2.3.18 to test compatibility for 2.4 ? This are then only three kernel versions. Thanks, Hartmut
Re: Too many kernels in unstable
Guy Maor wrote: What about just keeping the last 2.0.x and the last 2.2.x ? I agree. One 2.0.x, one 2.2.x, eventually one 2.[34].x version. This has been discussed before, people agreed that there's too much of the kernel packages in there. You're the FTP admin, please act. Brian Mays wrote: That would be fine by me; however, some people might object because kernel improvements sometimes break things -- even in stable kernel branches. It is not so rare for someone to avoid upgrading to the next kernel version, because it breaks some obscure feature that he needs. That's not a reason enough for keeping 20MB stuff for every version of kernel, IMNSHO. If there is a problem, you can still downgrade to your old kernel image. Which you did preserve, didn't you[1]? Plus, all of those versions are kept on ftp.kernel.org for indefinite time. And you can file a bug to the BTS, too. [1] you doesn't refer to you personally, Brian. -- enJoy -*/\*- don't even try to pronounce my first name
Re: Too many kernels in unstable
Brian Mays [EMAIL PROTECTED] wrote:
Once 2.2.12 makes it out of Incoming, we will have 8 kernel versions in
the unstable distribution? Do we REALLY need to provide that many
versions of the kernel??
I hate to complain, but every time a new version of the PCMCIA modules
is released, I have to build a set of packages for EACH of these
kernels. It's starting to become a real pain in the ass.
Can't we keep the number down to something more manageable, say 4 at
most?
We now have:
kernel-{doc,headers,image,source}-2.0.35
kernel-{doc,headers,image,source}-2.0.36
kernel-{doc,headers,image,source}-2.2.1
kernel-{doc,headers,image,source}-2.2.5
kernel-{doc,headers,image,source}-2.2.7
kernel-{doc,headers,image,source}-2.2.9
kernel-{doc,headers,image,source}-2.2.10
kernel-{doc,headers,image,source}-2.2.12
My suggestion would be:
kernel-{doc,headers,image,source}-2.0.38
kernel-{doc,headers,image,source}-2.2.12
Can anybody provide arguements against just having two kernels?
--
I consume, therefore I am
pgpVWJfDIg4Z1.pgp
Description: PGP signature
Re: Too many kernels in unstable
Edward Betts wrote:
My suggestion would be:
kernel-{doc,headers,image,source}-2.0.38
kernel-{doc,headers,image,source}-2.2.12
Can anybody provide arguements against just having two kernels?
1- Sometimes a new `stable' kernel introduces new bugs or
problems. (Didn't Debian recommend 2.0.35 over 2.036 or
something similar).
2- Sometimes a new `stable' kernel breaks on another arch
(As I recall, there were some alpha-related problems in recent
2.2.X kernels).
Perhaps the last two kernels of the stable tree(s) is good.
We have more kernels now because 2.0.X didn't die after 2.2.X was
released. Doesn't that argue that 2.2.X wasn't ready?
Two cents. I don't have strong feelings about this really.
Peter
Re: Too many kernels in unstable
On Fri, 17 Sep 1999, Brian Mays wrote: brian brian [EMAIL PROTECTED] (Brian Mays) writes: brian brian Once 2.2.12 makes it out of Incoming, we will have 8 kernel brian versions in the unstable distribution? Do we REALLY need to brian provide that many versions of the kernel?? brian brian Guy == Guy Maor [EMAIL PROTECTED] writes: brian brian What about just keeping the last 2.0.x and the last 2.2.x ? brian brianThat would be fine by me; however, some people might object because briankernel improvements sometimes break things -- even in stable kernel brianbranches. It is not so rare for someone to avoid upgrading to the next briankernel version, because it breaks some obscure feature that he needs. brian brianPerhaps we should keep the last two versions of each branch? In this briancase, 2.0.35, 2.0.36, 2.2.10, and 2.2.12 (which is in Incoming). I briandon't know. Let's see whether anyone objects to just keeping two brianversions around. In another thread, I am dealing with exactly this problem. My machine hangs with 2.0.37 and 2.2.x, but is OK with 2.0.36. But had to take a piece of driver code from 2.0.37. There are quite a few new issues arising from two gcc branches and two stable kernel branches. Having a few kernels around gives some flexibility in trying to put together a working system. 11 kernels is probably too much, but a couple of each might be OK. We (someone !) could also package the patches, which is a bit more of a pain for the user, but we could get all 12 new kernels without adding so much bulk to the archive. John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Re: Too many kernels in unstable
John Lapeyre [EMAIL PROTECTED] wrote: In another thread, I am dealing with exactly this problem. My machine hangs with 2.0.37 and 2.2.x, but is OK with 2.0.36. But had to take a piece of driver code from 2.0.37. There are quite a few new issues arising from two gcc branches and two stable kernel branches. I understand. I tried installing 2.2.12 on my laptop and noticed that I was having trouble with the APM support. Therefore, I returned to the 2.2.10 version. Having a few kernels around gives some flexibility in trying to put together a working system. 11 kernels is probably too much, but a couple of each might be OK. We (someone !) could also package the patches, which is a bit more of a pain for the user, but we could get all 12 new kernels without adding so much bulk to the archive. I could definitely live with this. I wouldn't need to build PCMCIA modules for patches. On a side note, years ago (when I had a smaller laptop), I used to use patches quite frequently to get the PCMCIA modules built for the various kernels provided by Debian. This worked, for the most part, but I eventually abandoned this technique when I started to have problems building modules that were truly compatible with the kernels. Building kernel modules is a tricky business; extra care taken from the beginning saves much time later rebuilding. Brian
