Re: kernel-{image,headers} package bloat
* Nils Rennebarth | Instead of creating lots of different kernel-image packages what about | a package that can create a kernel-image from source and gives you a list of | some more or less generic kernel to choose from? Abusing debconf, since it is such a nice interface. ;) I'd prefer if Herbert were to maintain this, since he is already doing all the different kernel configs. It's really easy: #! /bin/sh . /usr/share/debconf/confmodule db_input critical kernelconfig/config || true db_go db_get kernelconfig/config if [ "$RET" = "i386" ]; then cp /usr/share/kernel-configs/config.i386 /usr/src/linux/.config elif [ "$RET" = "i486" ]; then cp /usr/share/kernel-configs/config.i486 /usr/src/linux/.config fi db_purge -- You get the idea. The template file which goes with it is something like: Template: kernelconfig/config Type: select Default: i386 Choices: i386, i486, i586, i686, i686-smp Description: Which config file? Please choose the config file you would like to use when compiling -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: kernel-{image,headers} package bloat
On Tue, May 01, 2001 at 01:38:38PM +0200, Torsten Landschoff wrote: > Anyway, I would like to have an smp kernel readily available in Debian. > Mandrake for example installs the SMP kernel by default if the target > machine is a smp box. If another kernel-image is needed to support that > I can life with only UP. > > Basically I don't care if our distributed kernels squeeze the last 10% > out of the processor(s). But in an ideal world it should at least support all > installed processors so that I don't lose 100% compared to a custom kernel. > Anyway, if it's impossible to do that without adding bloat I can do without. Instead of creating lots of different kernel-image packages what about a package that can create a kernel-image from source and gives you a list of some more or less generic kernel to choose from? Nils -- *New* *New* *New*- on shellac records Windows HE- see top 10 reasons to downgrade on Historical Edition http://www.microsoft.com/windowshe pgp50vXndrHDc.pgp Description: PGP signature
Re: kernel-{image,headers} package bloat
On Tue, May 01, 2001 at 12:19:29AM +1000, Craig Sanders wrote: > > This is the point where I disagree. I really hate having to build my > > own kernel just to do some tests with a fresh installation. > > so you have spent good money on a high-end SMP machine but you're not > willing to put in 5(*) minutes work (running "make config" or menuconfig or > xconfig) to build a kernel which is optimised for your hardware. > > strange. Yes, really strange. When I had money I spent it on buying a SMP machine since I wanted to experiment with parallel code. It's now only half a year since I actually had the money to buy two PII-400 processors to actually make use of the SMP feature. Not to mention that the board has 2 UW-SCSI Slots but I have only a 4GB DDRS drive which is slow as hell compared to current disks. And it is not 5 minutes time but 5 minutes on top on each installation. And, BTW: It's even 5 minutes if I don't need to build a new kernel since I have to reboot to get into the new system and that takes quite a long time on this system even without Zope being installed. I wouldn't have commented this but I am getting really pissed if somebody accuses me of not being willing to spend x minutes on something. I am doing all my Debian work in my spare time and if 5 minutes of that perhaps 60 a day go away for senseless work I think it is okay if I don't like that. > of machine if you have a bunch of similar or identical machines). after > that, it's less work because you can re-use the old .config file and > just run "make oldconfig" to handle any new compile-time options. It's even less work since I have my kernel .deb around. Anyway, I would like to have an smp kernel readily available in Debian. Mandrake for example installs the SMP kernel by default if the target machine is a smp box. If another kernel-image is needed to support that I can life with only UP. Basically I don't care if our distributed kernels squeeze the last 10% out of the processor(s). But in an ideal world it should at least support all installed processors so that I don't lose 100% compared to a custom kernel. Anyway, if it's impossible to do that without adding bloat I can do without. cu Torsten pgpb99fmldzp3.pgp Description: PGP signature
Re: kernel-{image,headers} package bloat
* "Vince Mulhollon" | But what happens when people provide / request / demand optimized | versions of Gnome, KDE, and Apache for every possible combination of | optimization? You point them to pentium-builder, or Debian moves to a 'make world' paradigm. Or we bloat the archives a lot. I hope for the first most and the last least. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: kernel-{image,headers} package bloat
On Thu, Apr 26, 2001 at 05:39:34PM +0200, Kenneth Vestergaard Schmidt wrote: > If instead, you were able to type something akin to "update-kernel" or > whatever, and then have a kernel built suited to your arch, but with the > "default" Debian-options (ie. lotsa modules), wouldn't that be better? I > mean, just make a note to the user, to switch to another console, or minimize > the window in case of X. Then he'll get a kernel freshly built. IMHO, that's A compromise would be for the kernel-image- build environment for each kernel-image- to be packaged as, say "kernel-builder-2.4.4-686-smp", which would (I guess) consist of a depends on kernel-package, initrd-tools and mkcramfs, a script to make and install the kernel using make-kpkg, and the linux/.config file needed for that particular configuration. I'd suspect that each of these packages would be of the order of 64kbytes maximum. -- Paul Martin <[EMAIL PROTECTED]>
Re: kernel-{image,headers} package bloat
On 04/30/2001 03:21:55 PM "Christopher C. Chimelis" wrote: >> Basically, I can understand everyone's desires for a kernel that covers >> their cases (SMP, UP, 686, 386, etc), but the bloat issue that initially I can't understand that desire for such a small gain, but whatever. >> this thread gets more and more Intel/AMD-centric, I'm beginning to wonder >> what the larger implications may be... I would think an even scarier larger implication is that on my desktop machines, it's not unusual to have less than 10% kernel utilization. Thus even in the wildest dreams, no level of "optimization" can have more than a 2% effect on overall CPU speed. But what happens when people provide / request / demand optimized versions of Gnome, KDE, and Apache for every possible combination of optimization? I'm sure an optimized libc would have more impact that an optimized kernel. I'm sure my webserver would benefit far more from "optimized" Apache and Perl than it would from an "optimized" kernel, based on crude observations of the "top" command. The problem is not providing "optimized" versions of one "little" package, the problem is opening the floodgates to recompiles of every package in Debian with every possible combination of optimization. In an example that is fairly silly, if I recompile the kernel for a machine with a CPU that costs $300 (my processors are usually cheaper) and it gets a 20% kernel performance boost (totally unrealistic daydream) and it typically spends 10% of it's time in kernel space (probably less), that's the equivalent of saving me $6 over the cost of just buying the next faster processor. Now compare $6 to the cost of the electricity to run the box, or my salary to properly install and test the "optimized" kernel and I just don't see the payoff. Then there are the non-monetary costs, someone spending time making 20 different compilations of the same package is not spending time fixing bugs or playing Quake or drinking beer. Or on my firewall and kiosk machines using $50 special computers, the processor is probably worth $5 so I'd figure the optimizations save me 10 cents over the cost of upgrading the CPU to a faster one.
Re: kernel-{image,headers} package bloat
* Daniel Stone <[EMAIL PROTECTED]> [010424 07:03]: > ONE HUNDRED AND TEN MEGABYTES PER KERNEL RELEASE DOES NOT HELP MIRRORS WHICH > HAVE > OUT OF SYNC PACKAGES FILES AND ACTUAL PACKAGES HALF THE TIME. Being a maint. of two debian mirrors, I don't get your point. :) Could you please turn this into something that is worth arguing about, and find some mirrors that are actually configured to mirror at times that wont create a un-synched unstable area? This is a mirror-admin-setup-problem, and not a problem of the 'size' of the mirror. -- Scott Dier <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://www.ringworld.org/ [EMAIL PROTECTED] So little time, so little to do.-- Oscar Levant pgpoPtJ5ax9Yv.pgp Description: PGP signature
Re: kernel-{image,headers} package bloat
On Mon, 30 Apr 2001 [EMAIL PROTECTED] wrote: > Unfortunately it seems that a kernel that supports both i386 and SMP > would have to use very slow methods for locking since instructions > allowing faster locking only came in with the 486 and above. I'm wondering when this whole discussion will include other ports and their kernel requests... Basically, I can understand everyone's desires for a kernel that covers their cases (SMP, UP, 686, 386, etc), but the bloat issue that initially started this thread would be multiplied if the same type of solutions were implemented for the other archs. Alpha is now simplified, for the most part, and can use a "generic" kernel that doesn't suffer performance-wise, but we still have some exceptions (Ruffian, SMP, etc). If UP and SMP kernels were provided on i386, then we would request the same. I would assume sparc, powerpc, etc may also request the same. This could lead to an even larger archive bloat than this thread is trying to prevent... I've been clueless on how to solve this problem (or even what kind of solution may be needed to begin with since I don't see the current situation as being "a problem"), so I haven't spoken until now, but as this thread gets more and more Intel/AMD-centric, I'm beginning to wonder what the larger implications may be... C
Re: kernel-{image,headers} package bloat
On Mon, Apr 30, 2001 at 12:41:22PM +0200, Torsten Landschoff wrote: > This is the point where I disagree. I really hate having to build my > own kernel just to do some tests with a fresh installation. I think > the standard kernel should support SMP. I don't know if it causes > any problems with UP machines though... Unfortunately it seems that a kernel that supports both i386 and SMP would have to use very slow methods for locking since instructions allowing faster locking only came in with the 486 and above. Maybe there really ought to be exactly two kernels: 1) Uniprocessor kernel compiled for i386 (kernel-image-foo) 2) SMP kernel compiled for a suitable least common denominator of 95+% of SMP boards out there but using newer instructions for decent locking performance. Might not run on older UP boards or maybe a few really ancient SMP boards. The UP kernel would be used in the installer, but maybe the SMP version could be installed automatically on systems that support it. This would allow virtually everyone to get a kernel on their machine that would run at least very good (not perfect) performance while keeping the archive even less bloated than the old 'flavors' system. -- James Deikun, Techie(tm), CSI Multimedia The opinions expressed &c.
Re: kernel-{image,headers} package bloat
On Mon, Apr 30, 2001 at 12:41:22PM +0200, Torsten Landschoff wrote: > On Mon, Apr 30, 2001 at 05:19:12PM +1000, Craig Sanders wrote: > > anyone running SMP ought to have enough of a clue to compile their > > own kernel. > > This is the point where I disagree. I really hate having to build my > own kernel just to do some tests with a fresh installation. so you have spent good money on a high-end SMP machine but you're not willing to put in 5(*) minutes work (running "make config" or menuconfig or xconfig) to build a kernel which is optimised for your hardware. strange. IMO, it's even stranger when you consider that it's 5 minutes work only for the first time that you compile a kernel for that machine (or type of machine if you have a bunch of similar or identical machines). after that, it's less work because you can re-use the old .config file and just run "make oldconfig" to handle any new compile-time options. (*) i'm not including the 3-15 minutes (depending on CPU and disk speed and memory) it takes to actually compile the kernel because that can run in the background - it's not work, it's just waiting (or getting on with something else while it's compiling) craig -- craig sanders <[EMAIL PROTECTED]> GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
Hi Craig, On Mon, Apr 30, 2001 at 05:19:12PM +1000, Craig Sanders wrote: > > I won't go below that as an SMP kernel is always required, > > no it's not. > > anyone running SMP ought to have enough of a clue to compile their own > kernel. This is the point where I disagree. I really hate having to build my own kernel just to do some tests with a fresh installation. I think the standard kernel should support SMP. I don't know if it causes any problems with UP machines though... Basically I would like to have all machines supported by one kernel image. I don't care for the 10% (I guess this value is way to high) the optimization for better CPUs would buy but I certainly want to have my second processor working as well. And, lastly: Most of the time my processors are running in user mode especially when doing computing (read: cpu) intensive tasks. For web serving and the like the CPU load is quite low most of the time. Herbert, can you please tell me how much impact does the 10% optimization on my 2% system load do for me? Thanks Torsten pgphn37fDrC7M.pgp Description: PGP signature
Re: kernel-{image,headers} package bloat
On Sat, Apr 28, 2001 at 02:15:50PM +1000, Herbert Xu wrote: > Please also consider that if the user were to compile his own kernel, > he would face the problem of having to recompile the modules packages > if they're needed. use kernel-package and all the module packages are compiled automatically, with the modules_image target. craig -- craig sanders <[EMAIL PROTECTED]> GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Thu, Apr 26, 2001 at 07:48:02PM +1000, Herbert Xu wrote: > I won't go below that as an SMP kernel is always required, no it's not. anyone running SMP ought to have enough of a clue to compile their own kernel. why should everyone else pay the price for their cluelessness? > and the 686 flavour covers a very large chunk of the > i386 userbase. a 386 kernel covers all of the ia32 userbase. craig -- craig sanders <[EMAIL PROTECTED]> GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
Herbert Xu wrote: > With properly constructed dependencies, finding matching packages shouldn't > be an issue. Please also consider that if the user were to compile his own > kernel, he would face the problem of having to recompile the modules > packages if they're needed. Please explain how properly constructed dependancies can help a user find the right alsa and pcmcia modules packages out of a list of what will surely be near to a hundred modules packages. -- see shy jo
Re: kernel-{image,headers} package bloat
On Sun, Apr 29, 2001 at 10:34:03AM +0800, zhaoway wrote: > > i vote for alot of binary kernels. but i'd rather see someone comes > out will better ideas. if we are voting here, i'd vote for the very minimul number of stock kernels. if someone wants something more tuned, then roll your own, or the wonderful idea of some automated hardware detector that tunes a very nice kernel, along with the required modules (alsa, pcmcia, lids, crypto) -john
Re: kernel-{image,headers} package bloat
> > What about other kernel modules packages that are part of debian? > > Will we need 6 or 7 pcmcia-modules-2.2.3-* packages, for example? that's difficult to resolve. take alsa for example. if user compiles their own kernel, then they will have to compile their own alsa. since the protocol used in between alsa kernel modules and alsaplayer are version dependent, the user will have to figure it out and compile their own version of alsaplayer, ... if we build alot of binary kernel, then we will have to build alot of alsa-modules too. it will take more mirror space. even though it's better than the above, it's still not perfect, and you know a kernel-image deb is more than 7M to download, ... i vote for alot of binary kernels. but i'd rather see someone comes out will better ideas. -- http://dim.sourceforge.net ... Debian Chinese Input Method http://njlug.sourceforge.net NanJing GNU/Linux User Group http://cdlinux.sourceforge.net ... Debian running on Live! CDs http://people.debian.org/~zw .. XEmacs Screenshots
Re: kernel-{image,headers} package bloat
Herbert Xu wrote: > > Now, my gut instinct says that, as of this moment in time, no one has > > addressed the building of this initrd, to use at boot time, AFTER > > installation. Yes, we may have an installation initrd, but, in almost all > > circles, that is going to be different that what is used after the system is > > installed. Has this boot time initrd been constructed? Do we know how we > > are > > going to do that? > > If you're referring to the bits on the installation media, then it's a > question for the debian-installer folks to answer. And IIRC they have > already done it. To answer doogies's question: There is a initrd-tools package that makes the initrd used to boot the fully installed debian system every time it boots up (until you build a monolithic kernel or choose not to use initrd, or whatever). Herbert maintains this package, btw. To answer Herbert's mistaken interpretation of doogie's question: Yes, debian-installer has its own initrd too. It's pretty wacky. See preior discussion on debian-boot for details if you're interested. -- see shy jo
Re: kernel-{image,headers} package bloat
I'm coming in a bit late, but I have not seen this addressed in the thread: What about other kernel modules packages that are part of debian? Will we need 6 or 7 pcmcia-modules-2.2.3-* packages, for example? If so, that quickly grows beyone unweildly, both in archive size (Craig's complaints are magnified) and in user confusion trying to find a kernel and matching pcmcia, alsa, etc, etc modules packages to go with it, from a greatly expended list. -- see shy jo
Re: kernel-{image,headers} package bloat
On Fri, Apr 27, 2001 at 09:46:26PM -0400, Joey Hess wrote:
> I'm coming in a bit late, but I have not seen this addressed in the
> thread: What about other kernel modules packages that are part of
> debian? Will we need 6 or 7 pcmcia-modules-2.2.3-* packages, for
> example?
Yes. However, we already have 4 pcmcia-modules packages anyway. I don't
see a great problem in increasing it to 7. In any case, their archive size
is small compared to the kernels.
> If so, that quickly grows beyone unweildly, both in archive size
> (Craig's complaints are magnified) and in user confusion trying to find
> a kernel and matching pcmcia, alsa, etc, etc modules packages to go with
> it, from a greatly expended list.
With properly constructed dependencies, finding matching packages shouldn't
be an issue. Please also consider that if the user were to compile his own
kernel, he would face the problem of having to recompile the modules
packages if they're needed.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: kernel-{image,headers} package bloat
On Thu, Apr 26, 2001 at 04:20:46PM +1000, Craig Sanders wrote: > On Wed, Apr 25, 2001 at 02:18:30AM +1000, Daniel Stone wrote: > > I could disagree pretty heavily by pointing that this would be shit as > > it would add an hour to the install. Why not just provide a stock i386 > > kernel and let people compile it later on? Some people need to patch > > in mm/swap patches, netfilter patches, their own hacks, etc, etc. > > please pay attention. I have been, oddly enough. > nobody (at least as far as i can tell) has suggested getting rid of the > stock kernel-image package, so there will be no effect at all on people > who just want to install the system and run it. AFAIK, you suggested adding a "compile your own kernel" step at install time. Which would be bad. AFAIK. Bear in mind "02:18:30AM +1000". > the point at issue is whether there should be dozens of kernel-image and > kernel-headers packages when one is enough to do the job. I know, this is shit. Pay attention to my other postings on the other part of this thread and you'll see. -- Daniel Stone [EMAIL PROTECTED]
Re: kernel-{image,headers} package bloat
On Thursday 26 April 2001 08:20, Craig Sanders wrote:
> the point at issue is whether there should be dozens of kernel-image and
> kernel-headers packages when one is enough to do the job.
I'm just a humble Linux-user, but still compile my own kernel. However, I do
this because I'm also a control-freak, and I like to know what is compiled
into it. I also like to decide /what/ modules I have, instead of everything.
But that's me.
If I understand this correctly, Herbert Xu wants to provide alternate
kernel-* to make it easier for users to run a better suited kernel. However,
doesn't that require the user to know more about his system? I would argue in
/favor/ of the kernel-{helper,custom} package, since if you wanted to use a
custom kernel, you still had to use apt/dselect/whatever to find the correct
image for your system. And if you /REALLY/ want those last drops of
performance, you still need to be something of a wizzard, using powertweak,
or /proc-hacks, or whatever.
If instead, you were able to type something akin to "update-kernel" or
whatever, and then have a kernel built suited to your arch, but with the
"default" Debian-options (ie. lotsa modules), wouldn't that be better? I
mean, just make a note to the user, to switch to another console, or minimize
the window in case of X. Then he'll get a kernel freshly built. IMHO, that's
much better. It also means that they only have to download a small update
each time there's a new kernel-release, instead of several megabytes. Dial-up
users should love this.
In the end, I am not sure this matters. Herbert seems to have set his mind
pretty strongly on this. I can't speak on behalf of him, of course, but it
seems that "multiple flavours" are here to stay, for better or for worse...
Regards
Kenneth
Re: kernel-{image,headers} package bloat
On Wed, 25 Apr 2001, Adam Heath wrote: > On Wed, 25 Apr 2001, Dale Scheetz wrote: > > > On Wed, 25 Apr 2001, Wichert Akkerman wrote: > > > > > Previously Dale Scheetz wrote: > > > > Then you break things for no good reason. These "module builders" you > > > > speak of should be using the same headers as glibc. > > > > > > Absolutely definitely not. Userland is different from kernelspace, > > > and headers need not match at all. Feel free to search debian-devel > > > or linux-kernel archives where that has been discussed way too > > > often already. > > > > Kernel modules exist in kernelspace, not userland. Building them against > > any other headers than those used by glibc does nothing to improve the > > stability or usefulness of Debian. > > Ah, self-contradictory statement. > > A kernel-module must be built with the EXACT SAME environment as the kernel > being run. This means they need an EXACT match of headers. The ones that are > included with glibc are generic, and will NEVER match the running kernel(even > across kernel versions, let alone flavors). > > Dale, get a clue about kernel module building. You are completely wrong on > this. You're right, I'm an idiot. I have no idea what I was thinking... I also don't know why I got diverted from the issue of bloat. The idea of "flavours" seems to go beyond the version connectedness required by kernel drivers. We have always delivered a kernel-header package for each version of the kernel that we deliver. What is there about the modules problem that suggests there should be even more flavours? The difference in architectures is a simple symlink to the proper asm routines. What else needs to be "tailored" that can't be handled in postinst. The last thing we need in this distribution is more packages... Luck, Dwarf -- _-_-_-_-_- Author of "Dwarf's Guide to Debian GNU/Linux" _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 08:27:18PM -0400, Josh Huber wrote:
>
> Yes, which is different -- we have 4 kernel-image packages for
I'm open to suggestions as to which of the images can be dropped.
As far as I can see, there are two arguments against the present organisation
on i386:
1. The kernel images provide no/little benefit for our users.
2. The kernel images impose a strain on the mirrors that we can do without.
1 is a matter of opinion, and one which I do not agree with.
I do understand that everyone is operating under constrained resources. So
I'm always on the lookout for images that have little use or images that
can be merged. In particular, pentium4 will go in the next release as
there is very little demand for it, and for those who actually have it,
I doubt compiling the kernel is very time consuming [1].
This will bring the number of images down to 7, or in terms of size, about
70MB.
I'm willing to further reduce that to as little as 3 with the removal of
586/586tsc/k6/k7. However, I would like to see concrete evidence from
mirror operators that this 40M poses a significant problem for them before
I take this route as except k7, the three flavours take significant to
compile on their respective hosts. I won't go below that as an SMP kernel
is always required, and the 686 flavour covers a very large chunk of the
i386 userbase.
As to the kernels on the alpha architecture which I also maintain, I have
no plans whatsoever to go down this optimisation route as there simply
aren't enough users to justify the costs involved. It is also the case
that I simply to have an Alpha box that's sexy enough to do this :)
I cannot comment about the kernel maintainers on other architectures of
course. But I'm sure they will make the most sensible decisions for them.
[1] The point of this exercise is not to make it easier for people who don't
know how to compile kernels to be able to use optimised kernels. It is
for those who don't have a grunty box to keep up with the them.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: kernel-{image,headers} package bloat
Aaron Lehmann <[EMAIL PROTECTED]> wrote:
> I've said before that over 2000 kernel configuration options exist and
Most of which can be decided at runtime once you start using initrd.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: kernel-{image,headers} package bloat
On Thu, Apr 26, 2001 at 04:15:24PM +1000, Craig Sanders wrote: >On Wed, Apr 25, 2001 at 09:56:58PM -0500, Rob Browning wrote: >> Just in case anyone else was confused, I'm still in favor of having at >> least *one* precompiled kernel per-architecture, so no one *has* to >> compile a kernel, > >i think everyone is in favour of that. > >the issue is whether it's appropriate to have a dozen or so kernel-image >packages (and associated kernel-headers packages) per kernel version, >when one(*) will do. Don't forget the proliferation of kernel modules in that count. This has already started with alsa recently, and I expect that more will follow before too long: alsa-modules-2.4.3-386 alsa-modules-2.4.3-586 alsa-modules-2.4.3-586tsc alsa-modules-2.4.3-686 alsa-modules-2.4.3-686-smp alsa-modules-2.4.3-k6 alsa-modules-2.4.3-k7 alsa-modules-2.4.3-pentium4 alsa-modules-2.4.3-pentiumiii alsa-modules-2.4.3-pentiumiii-smp kernel-headers-2.4.3 kernel-headers-2.4.3-386 kernel-headers-2.4.3-586 kernel-headers-2.4.3-586tsc kernel-headers-2.4.3-686 kernel-headers-2.4.3-686-smp kernel-headers-2.4.3-k6 kernel-headers-2.4.3-k7 kernel-headers-2.4.3-pentium4 kernel-headers-2.4.3-sparc kernel-image-2.4.3-386 kernel-image-2.4.3-586 kernel-image-2.4.3-586tsc kernel-image-2.4.3-686 kernel-image-2.4.3-686-smp kernel-image-2.4.3-k6 kernel-image-2.4.3-k7 kernel-image-2.4.3-pentium4 Regards, -- Brendan O'Deabod@compusol.com.au Compusol Pty. Limited (NSW, Australia) +61 2 9810 3633
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 02:18:30AM +1000, Daniel Stone wrote: > I could disagree pretty heavily by pointing that this would be shit as > it would add an hour to the install. Why not just provide a stock i386 > kernel and let people compile it later on? Some people need to patch > in mm/swap patches, netfilter patches, their own hacks, etc, etc. please pay attention. nobody (at least as far as i can tell) has suggested getting rid of the stock kernel-image package, so there will be no effect at all on people who just want to install the system and run it. the point at issue is whether there should be dozens of kernel-image and kernel-headers packages when one is enough to do the job. craig -- craig sanders <[EMAIL PROTECTED]> GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 09:56:58PM -0500, Rob Browning wrote: > Just in case anyone else was confused, I'm still in favor of having at > least *one* precompiled kernel per-architecture, so no one *has* to > compile a kernel, i think everyone is in favour of that. the issue is whether it's appropriate to have a dozen or so kernel-image packages (and associated kernel-headers packages) per kernel version, when one(*) will do. (*) or whatever the minimum number is that will boot on all ia32 boxes. craig -- craig sanders <[EMAIL PROTECTED]> GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On 25 Apr 2001 21:56:58 -0500, Rob Browning wrote: > > Just in case anyone else was confused, I'm still in favor of having at > least *one* precompiled kernel per-architecture, so no one *has* to > compile a kernel, but if they want a customized kernel, then, > presuming the idea has merit, they would need to install the > kernel-custom package, make a selection, and wait a bit. > I'm going to have to agree on this one. I don't think anyone should be forced to compile a kernel, but if you care enough to want the optimizations then you should go through the process of doing it for yourself. That way, things will keep working quite well for those who want it to just work, and for those who want to shear off a few k of memory, they can do it for themselves. Everyone has a working kernel, module debate is moot, extra mirror load is nil, and most all the other major points of contention go away as well. Just my $0.02 - David Nusinow [EMAIL PROTECTED]
Re: kernel-{image,headers} package bloat
Dave Benson <[EMAIL PROTECTED]> writes: > i'm an idiot. i wasted bandwidth and answered my own question. Don't worry about it. Just in case anyone else was confused, I'm still in favor of having at least *one* precompiled kernel per-architecture, so no one *has* to compile a kernel, but if they want a customized kernel, then, presuming the idea has merit, they would need to install the kernel-custom package, make a selection, and wait a bit. -- Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
Re: kernel-{image,headers} package bloat
[from rob browning] > > prevent us from having a minimal set of kernel packages per arch, > > maybe even just one, and then having a kernel-custom package that pops > > up a debconf gui when installed, listing all the available [from myself] > [*] now, in fairness i often use the stock kernel anyways... i'm an idiot. i wasted bandwidth and answered my own question. sorry, dave
Re: kernel-{image,headers} package bloat
> I think someone else suggested something similar, but what would > prevent us from having a minimal set of kernel packages per arch, > maybe even just one, and then having a kernel-custom package that pops > up a debconf gui when installed, listing all the available > configurations[1], and once selected, builds and installs the > requested kernel, with all the modules that have been installed as > source packages. i am, i think, one of many people who look forward to not having to compile kernels anymore. [*] this is, after all, debian, not bsd. whether we need all the variants, please don't ask me. but whether we should have to compile on our machine: i'd really rather not. thanks, dave [*] now, in fairness i often use the stock kernel anyways...
Re: kernel-{image,headers} package bloat
David Schleef <[EMAIL PROTECTED]> writes: > I develop/maintain several packages that compile kernel modules > outside the kernel source, and understand a lot about what is > necessary to compile modules outside the kernel. I have yet to see > a header package in any distro that is actually useful in doing > non-trivial module compilation -- there's just too much in the > kernel that building modules _could_ depend on, such as including > Makefile fragments, .config, scripts/makedep, etc. Right now, the > rift between what is neccessary (for me) and what is available is so > large that I always recommend to people to build their own kernel, > even if it is a standard configuration. I'd be willing to help, > since I think it is a good goal, but I think this thread is > worthless. Maybe this is untenable, but it's not like we're running Windows here. We have amazingly powerful tools available, including the ability to install a set of packages that can actually build the kernel itself. I think someone else suggested something similar, but what would prevent us from having a minimal set of kernel packages per arch, maybe even just one, and then having a kernel-custom package that pops up a debconf gui when installed, listing all the available configurations[1], and once selected, builds and installs the requested kernel, with all the modules that have been installed as source packages. [1] For extra brownie points, have one option on the gui be "Run make config directly?" and also make the FS location of the .config file public so people can just "cp" one there. Also write the scripts to properly use "make oldconfig" as appropriate. (BTW, Thanks Craig -- I had no idea that even existed...) Other than the time required to build the kernel, this seems like it might be better from a mirror storage perspective and from a "did I get the right kernel and modules" perspective. It seems like we have all the needed bits to do this, and it would be *really* cool IMO. As far as this thread is concerned. I'm really sorry to see it. It's been a long time since I was watching debian-devel, and rather than seeing people, many of whom I have substantial technical respect for, working to try and understan the legitimate issues on both sides and then to find a superior solution, I see them beating the crap out of each other and wasting a lot of time. Then again, if that wasn't happening, I suppose I'd proabably wonder if I was reading the wrong list :> -- Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 08:27:18PM -0400, Josh Huber wrote: > now what do we have? > > kernel-image-version-- To be more complete we could have: kernel-image I've said before that over 2000 kernel configuration options exist and it's obviously not feasable to make a standard binary kernels with every concievable combination. Of these options, CPU optionizations are probably the least important.
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 07:33:50PM -0400, Daniel Jacobowitz wrote:
> On Wed, Apr 25, 2001 at 06:07:50PM -0400, Josh Huber wrote:
> > Craig Sanders <[EMAIL PROTECTED]> writes:
> >
> > > i am, and always have been, talking about the bloated number of
> > > kernel-{image,headers} packages.
> >
> > I have to admit, I strongly disagree with having separate packages for
> > every flavor of i386 machines. What about the other architectures as
> > well? Should we have versions for every revision of the Alpha?
> > powerpc too? this seems like an incredible waste of mirror space &
> > bandwidth, and it looks like virtually every Developer here thinks
> > this is a bad idea. I wonder why that is?
>
> Actually, we do have equivalent kernel packages for most of the (e.g.)
> PowerPC variants. There it is a little more necessary than here, since
> the kernels only boot on one flavor. There'll be even more when I
> start building kernel packages on a faster machine.
>
> Alpha is, I believe, the same way. As is ARM, and possibly sparc...
>
FWIW, I do compile my own kernel. That said, here's some facts:
ftp://ftp.us.debian.org/debian/dists/stable/main/binary-alpha/base/
shows 21! different v2.2.13 kernel-images.
ftp://ftp.us.debian.org/debian/dists/stable/main/binary-arm/base/
shows 1 v2.2.10 kernel-image
ftp://ftp.us.debian.org/debian/dists/stable/main/binary-i386/base/
shows 4 different v2.2.17 kernel-images
ftp://ftp.us.debian.org/debian/dists/stable/main/binary-m68k/base/
show 6 different v2.2.10 kernel-images
ftp://ftp.us.debian.org/debian/dists/stable/main/binary-powerpc/base/
show 3 different v2.2.15 kernel-images
ftp://ftp.us.debian.org/debian/dists/stable/main/binary-sparc/base/
show 5 different v2.2.17 kernel-images
I'm not sure why people are coming down on Herbert Xu here. If he
decides as the maintainer of the kernel-images to provide flavors for
various CPU types within the i386 family, that is his perogative, right?
Sounds like the main argument is mirror space. Now consider the 21
different v2.2.13 kernel-images available for alpha. If it were possible
to determine the percentage of people using debian on each of the 21
different flavors, then compare that to percentage of people using
different flavors of i386, then depending on the result there could be
an argument made for/against based on that kind of data.
Do alpha and the other architectures really have that many flavors of
CPU's? Are they all binary incompatible with each other, or do they have
a minimal compatibility standard (eg i386)?
Gordon Sadler
Re: kernel-{image,headers} package bloat
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > Actually, we do have equivalent kernel packages for most of the (e.g.) > PowerPC variants. There it is a little more necessary than here, since > the kernels only boot on one flavor. There'll be even more when I > start building kernel packages on a faster machine. Yes, which is different -- we have 4 kernel-image packages for powepc. chrp, prep, pmac, and apus. All different variants that are different enough to warrent different binary kernel packages. Actually, is that true? It was my understanding that APUS was the only one that needed a different kernel build. Although I guess there are the differences in which kernel image (vmlinux, zImage, etc) is needed to boot your particular subarchitecture. BUT -- this is *different* than the i386 situation! We're not going to start building a different kernel for every powerpc cpu type are we? 601, 603(e), 604(e), 7xx, 74xx, and those are just the non-embedded version. now what do we have? kernel-image-version-- that's what? 4 subarchs...well, let's say 3, because AFAIK APUS is pretty limited in CPU choice. 3 * 5 cpu variants...15 kernel-image packages for powerpc alone? > Alpha is, I believe, the same way. As is ARM, and possibly sparc... it just seems excessive, _unless_ they're required to boot different subarchs. just IMHO, of course. -- Josh Huber | [EMAIL PROTECTED] |
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 06:07:50PM -0400, Josh Huber wrote:
> Craig Sanders <[EMAIL PROTECTED]> writes:
>
> > i am, and always have been, talking about the bloated number of
> > kernel-{image,headers} packages.
>
> I have to admit, I strongly disagree with having separate packages for
> every flavor of i386 machines. What about the other architectures as
> well? Should we have versions for every revision of the Alpha?
> powerpc too? this seems like an incredible waste of mirror space &
> bandwidth, and it looks like virtually every Developer here thinks
> this is a bad idea. I wonder why that is?
Actually, we do have equivalent kernel packages for most of the (e.g.)
PowerPC variants. There it is a little more necessary than here, since
the kernels only boot on one flavor. There'll be even more when I
start building kernel packages on a faster machine.
Alpha is, I believe, the same way. As is ARM, and possibly sparc...
--
Daniel Jacobowitz Debian GNU/Linux Developer
Monta Vista Software Debian Security Team
Re: kernel-{image,headers} package bloat breaks module builders
> "Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes: Herbert> I doubt the increase is going to be that significant. Herbert> Since most of these will eventually become part of the Herbert> mainstream kernel or get dropped. I hope that is not actually the trend we see. >> image. Herbert> If your module source is properly constructed, you should Herbert> be able to get away with a build-depends on the No, I can't. kernel-package, which is the exported public interface for building modules on Debian does not support this. Convince Manoj to support kernel-headers packages for modules and you have a much more reasonable argument.
Re: kernel-{image,headers} package bloat
Craig Sanders <[EMAIL PROTECTED]> writes:
> i am, and always have been, talking about the bloated number of
> kernel-{image,headers} packages.
I have to admit, I strongly disagree with having separate packages for
every flavor of i386 machines. What about the other architectures as
well? Should we have versions for every revision of the Alpha?
powerpc too? this seems like an incredible waste of mirror space &
bandwidth, and it looks like virtually every Developer here thinks
this is a bad idea. I wonder why that is?
--
Josh Huber | [EMAIL PROTECTED] |
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 01:16:51AM -0500, Adam Heath wrote: > A kernel-module must be built with the EXACT SAME environment as the kernel > being run. This means they need an EXACT match of headers. The ones that are > included with glibc are generic, and will NEVER match the running kernel(even > across kernel versions, let alone flavors). Ok, we established that the flavored kernel-headers packages are to build modules for the debian-provided kernels by yourself. This is legitimate imho, because it is *not* only for people who may want to distribute binary modules but may come handy if I had a network card supported only by a newer version of the driver: Get the new version, compile it as a module, hardware runs. *BUT* as someone else mentioned, the cases where you get away with a full kernel source and only need what kernel-headers provide are so few, that it isn't really worth supporting them. People who need to build modules for the debian supplied kernel that are not already there should use the full kernel source and use the .config of their kernel-image to create modules with symbols matching their running kernel. Nils -- *New* *New* *New*- on shellac records Windows HE- see top 10 reasons to downgrade on Historical Edition http://www.microsoft.com/windowshe pgpj4o1a0eyr9.pgp Description: PGP signature
Re: kernel-{image,headers} package bloat
On Wed, 25 Apr 2001, Dale Scheetz wrote: > On Wed, 25 Apr 2001, Wichert Akkerman wrote: > > > Previously Dale Scheetz wrote: > > > Then you break things for no good reason. These "module builders" you > > > speak of should be using the same headers as glibc. > > > > Absolutely definitely not. Userland is different from kernelspace, > > and headers need not match at all. Feel free to search debian-devel > > or linux-kernel archives where that has been discussed way too > > often already. > > Kernel modules exist in kernelspace, not userland. Building them against > any other headers than those used by glibc does nothing to improve the > stability or usefulness of Debian. Ah, self-contradictory statement. A kernel-module must be built with the EXACT SAME environment as the kernel being run. This means they need an EXACT match of headers. The ones that are included with glibc are generic, and will NEVER match the running kernel(even across kernel versions, let alone flavors). Dale, get a clue about kernel module building. You are completely wrong on this.
Re: kernel-{image,headers} package bloat
On Wed, 25 Apr 2001, Wichert Akkerman wrote: > Previously Dale Scheetz wrote: > > Then you break things for no good reason. These "module builders" you > > speak of should be using the same headers as glibc. > > Absolutely definitely not. Userland is different from kernelspace, > and headers need not match at all. Feel free to search debian-devel > or linux-kernel archives where that has been discussed way too > often already. Kernel modules exist in kernelspace, not userland. Building them against any other headers than those used by glibc does nothing to improve the stability or usefulness of Debian. We don't try to control the version or configuration of the kernel on working Debian systems. We only control the kernel provided for installation. Trying to provide the special kernel feature needed by some perculiar third party module, by providing a wide variety of "flavours" in kernel-headers, is a philosophically broken point of view at the very lease, and technically redundant to boot. These statements are obviously based on my personal point of view, and I've always been opposed to the kernel source in .deb format, but if we're going to do it that way, then use the package manager tools to configure this source on the target machine, providing proper compilation headers for the installation architecture. Personally I have no use for even the .dsc, .diff, and .tar.gz source, but acquire all my kernel source from "the source". Which reminds me, thanks for the pointer to the new 2.2.19 kernel, seems to have fixed all my problems. It even recognizes all 128 meg of memory without need of the mem= argument to LILO! (which is just as well because I couldn't seem to get the syntax right anyway ;-) I just barely got this one to squeeze into a zImage, so it doesn't seem to matter that I'm strongly opposed to bloat. It happens anyway... Personally, I can't imagine why Herbert wants to put more packages on his management plate in the first place, much less why he thinks its good for the rest of us. I'm doing my best to get rid of the useless, dangling packages in my hands! Luck, Dwarf -- _-_-_-_-_- Author of "Dwarf's Guide to Debian GNU/Linux" _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: kernel-{image,headers} package bloat
Previously Dale Scheetz wrote: > Then you break things for no good reason. These "module builders" you > speak of should be using the same headers as glibc. Absolutely definitely not. Userland is different from kernelspace, and headers need not match at all. Feel free to search debian-devel or linux-kernel archives where that has been discussed way too often already. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: kernel-{image,headers} package bloat
On Wed, 25 Apr 2001, Herbert Xu wrote: > On Wed, Apr 25, 2001 at 08:54:33AM -0400, Dale Scheetz wrote: > > On Wed, 25 Apr 2001, Herbert Xu wrote: > > > > > That is the raison d'etre for kernel-headers. However, the new per-image > > > kernel-headers exist solely for the benefit of module builders. > > > > Then you break things for no good reason. These "module builders" you > > speak of should be using the same headers as glibc. > > Hmm, I think you better refresh your theory about kernel modules. Right back at you... > > > > Huh? There is still a kernel-headers package for the glibc maintainer to > > > use. In fact, it's exactly the same as before. > > > > And when some other library gets built with one of your other headers? > > Which other library uses kernel headers? They better stop or they probably > won't compile at all with 2.4. This doesn't reduce the damage hole you are creating. > > > This is the sole reason for the existance of kernel-headers. Your > > continued insistance that doing something else is good for someone else > > ignores these reasons and is fundamentally a broken concept. > > Dale, I expected you to have a better understanding of this since you > used to maintain glibc. It is true that the plain kernel-headers exist > solely/mainly for the purpose of building glibc. However, it has nothing > to do with the new flavoured kernel-headers. These should/will not be > used to build glibc. They exist so that kernel modules with correct > checksums can be easily built. Well, first of all, my contribution to glibc development was that of the little boy with his finger in the dyke trying to stem the oncoming tide. I held the package after David dropped it, until Joel took it over. None of this is relevant to the current discussion. Please explain to me just how multiple header packages makes additional module creation more safe/useful/correct. Most of the third party module vendors (like VMware for instance) generate their needed modules at installation time, against the kernel source on the target machine. If all of this effort and bother is to make third party, binary only, module provider's lives better, I don't see how this accomplishes that. You give more than one choice and my karma provides the most wrong one in the group. You continue to demand good reasons not to do what you want, and ignoring all reasons provided. My question is: "Just how does this bloat improve the packages in main?" That is our goal, and supporting the needs of proprietary vendors in this fashion doesn't help those users who "need" non-free software. Until you can answer my question reasonably, I will continue to be opposed to your proposal. Luck, Dwarf -- _-_-_-_-_- Author of "Dwarf's Guide to Debian GNU/Linux" _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 08:54:33AM -0400, Dale Scheetz wrote:
> On Wed, 25 Apr 2001, Herbert Xu wrote:
>
> > That is the raison d'etre for kernel-headers. However, the new per-image
> > kernel-headers exist solely for the benefit of module builders.
>
> Then you break things for no good reason. These "module builders" you
> speak of should be using the same headers as glibc.
Hmm, I think you better refresh your theory about kernel modules.
> > Huh? There is still a kernel-headers package for the glibc maintainer to
> > use. In fact, it's exactly the same as before.
>
> And when some other library gets built with one of your other headers?
Which other library uses kernel headers? They better stop or they probably
won't compile at all with 2.4.
> This is the sole reason for the existance of kernel-headers. Your
> continued insistance that doing something else is good for someone else
> ignores these reasons and is fundamentally a broken concept.
Dale, I expected you to have a better understanding of this since you
used to maintain glibc. It is true that the plain kernel-headers exist
solely/mainly for the purpose of building glibc. However, it has nothing
to do with the new flavoured kernel-headers. These should/will not be
used to build glibc. They exist so that kernel modules with correct
checksums can be easily built.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: kernel-{image,headers} package bloat
On Wed, 25 Apr 2001, Herbert Xu wrote: > On Wed, Apr 25, 2001 at 08:18:00AM -0400, Dale Scheetz wrote: > > > > The whole purpose of kernel-headers is to provide one, most stable, kernel > > interface for the distro to build against. The idea was that, by choosing > > the kernel to compile against you have the best chance of things working > > correctly on other kernels. > > That is the raison d'etre for kernel-headers. However, the new per-image > kernel-headers exist solely for the benefit of module builders. Then you break things for no good reason. These "module builders" you speak of should be using the same headers as glibc. > > > Creating a kernel-header for "each flavour" completely ignores and > > defeates the reason that kernel-headers exist! > > Huh? There is still a kernel-headers package for the glibc maintainer to > use. In fact, it's exactly the same as before. And when some other library gets built with one of your other headers? This is the sole reason for the existance of kernel-headers. Your continued insistance that doing something else is good for someone else ignores these reasons and is fundamentally a broken concept. Strut all you want, but your just plain wrong. Waiting is, Dwarf -- _-_-_-_-_- Author of "Dwarf's Guide to Debian GNU/Linux" _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 08:18:00AM -0400, Dale Scheetz wrote:
>
> The whole purpose of kernel-headers is to provide one, most stable, kernel
> interface for the distro to build against. The idea was that, by choosing
> the kernel to compile against you have the best chance of things working
> correctly on other kernels.
That is the raison d'etre for kernel-headers. However, the new per-image
kernel-headers exist solely for the benefit of module builders.
> Creating a kernel-header for "each flavour" completely ignores and
> defeates the reason that kernel-headers exist!
Huh? There is still a kernel-headers package for the glibc maintainer to
use. In fact, it's exactly the same as before.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: kernel-{image,headers} package bloat
On Wed, 25 Apr 2001, Herbert Xu wrote: > There two discussions here: > > 1. The number of kernel flavours. > 2. The need for kernel-headers for each flavour. > > I was talking about 2. > The whole purpose of kernel-headers is to provide one, most stable, kernel interface for the distro to build against. The idea was that, by choosing the kernel to compile against you have the best chance of things working correctly on other kernels. Creating a kernel-header for "each flavour" completely ignores and defeates the reason that kernel-headers exist! As to point 1, the only reason I can see to have different kernels is to have one for installation (which can boot from various devices) and possibly another more moduled build for a running system, but I have to agree with "the opposition" when I say that delivering a couple of different image files is far less impact than a large number of source packages. Why not just one source package that does something like "make mrproper" during the postinstall so that the headers are set up correctly for the particular architecture it is installed upon. This satisfies both header and source needs. Herbert, you need to stop behaving like your namesake from Star Trek, and begin to listen to the overwhelming position of your fellow developers. Waiting is, Dwarf -- _-_-_-_-_- Author of "Dwarf's Guide to Debian GNU/Linux" _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 04:56:19PM +1000, Herbert Xu wrote:
> > a person/company producing a binary kernel module is FAR more likely to
> > create one for debian if they only have to create one module, rather
> > than a dozen or so.
>
> There two discussions here:
>
> 1. The number of kernel flavours.
> 2. The need for kernel-headers for each flavour.
>
> I was talking about 2.
i am, and always have been, talking about the bloated number of
kernel-{image,headers} packages.
sometimes that requires demolishing some of the digressions in order to
force things back to the point.
> > > You seem to be confusing the kernel-header discussion with the
> > > kernel-image discussion. Please go back and reread the thread.
> >
> > they're one and the same. "kernel-{image,headers} package bloat" has
> > been the topic of this thread from the beginning.
>
> In that case, you're mixing them up as well.
you are mistaken. i started the thread, i know what i started.
craig
--
craig sanders <[EMAIL PROTECTED]>
GnuPG Key: 1024D/CD5626F0
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 04:28:30PM +1000, Craig Sanders wrote:
> On Wed, Apr 25, 2001 at 10:31:46AM +1000, Herbert Xu wrote:
> >
> > Because someone asked why the kernel-headers necessary. Their
> > presence allows both our module maintainers and other maintainers
> > to compile modules easily. It doesn't mean that they will. But it
> > certainly makes it a lot more likely.
>
> no, it makes it a lot less likely.
>
> a person/company producing a binary kernel module is FAR more likely to
> create one for debian if they only have to create one module, rather
> than a dozen or so.
There two discussions here:
1. The number of kernel flavours.
2. The need for kernel-headers for each flavour.
I was talking about 2.
> > You seem to be confusing the kernel-header discussion with the
> > kernel-image discussion. Please go back and reread the thread.
>
> they're one and the same. "kernel-{image,headers} package bloat" has
> been the topic of this thread from the beginning.
In that case, you're mixing them up as well.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 10:31:46AM +1000, Herbert Xu wrote:
> On Tue, Apr 24, 2001 at 05:26:27PM -0700, Aaron Lehmann wrote:
> > Ok, so why did this come up at all in the discussion of the kernel
> > package bloat? It seems to me that providing optimized kernels is a
>
> Because someone asked why the kernel-headers necessary. Their
> presence allows both our module maintainers and other maintainers
> to compile modules easily. It doesn't mean that they will. But it
> certainly makes it a lot more likely.
no, it makes it a lot less likely.
a person/company producing a binary kernel module is FAR more likely to
create one for debian if they only have to create one module, rather
than a dozen or so.
even if they can be bothered putting in the effort to figure out exactly
what kernel-headers package(s) and how it all works, they need installed
it's still a lot more work to produce and support a dozen versions(*) of
their module rather than just one.
(*) per kernel version that they choose to support.
> You seem to be confusing the kernel-header discussion with the
> kernel-image discussion. Please go back and reread the thread.
they're one and the same. "kernel-{image,headers} package bloat" has
been the topic of this thread from the beginning.
craig
--
craig sanders <[EMAIL PROTECTED]>
GnuPG Key: 1024D/CD5626F0
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat breaks module builders
On Tue, Apr 24, 2001 at 10:57:18AM -0500, Adam Heath wrote: > On Wed, 25 Apr 2001, Daniel Stone wrote: > > > > Who says you have to compile debian packages on only machines you own? > > > > So tell elmo to get me through, and not, not do anything for 2 months. The > > only other faster machines I have access to, run RedHat or Mandrake, and I > > can't afford anything better for at least one or two months' time. > > Why does it matter what is running on the machine? Have you ever heard of a > chroot? Somehow, my managers (every single one of them) don't like the idea of running a Debian chroot on production systems. -- Daniel Stone [EMAIL PROTECTED]
Re: kernel-{image,headers} package bloat breaks module builders
On Wed, 25 Apr 2001, Daniel Stone wrote: > > Who says you have to compile debian packages on only machines you own? > > So tell elmo to get me through, and not, not do anything for 2 months. The > only other faster machines I have access to, run RedHat or Mandrake, and I > can't afford anything better for at least one or two months' time. Why does it matter what is running on the machine? Have you ever heard of a chroot?
Re: kernel-{image,headers} package bloat breaks module builders
On Wed, Apr 25, 2001 at 02:40:27AM +0200, Wichert Akkerman wrote: > Previously Daniel Stone wrote: > > Linux Kernel Developer > > I love this.. the only mention of 'daniel.*stone' in the entire > kernel is a trivial patch to drivers/sound/sb_card.c.. Plus, numerous Netfilter things, which I have no in-kernel credit for. And the Netfilter scoreboard started off well, but when Rusty got bogged down ... -- Daniel Stone (if you listen to Wichert, not a) Linux Kernel Developer [EMAIL PROTECTED]
Re: kernel-{image,headers} package bloat breaks module builders
On Tue, Apr 24, 2001 at 09:33:13AM -0500, Adam Heath wrote: > On Wed, 25 Apr 2001, Daniel Stone wrote: > > > On Wed, Apr 25, 2001 at 09:15:09AM +1000, Herbert Xu wrote: > > > I think your concerns are not well-founded. If you have a sane build > > > system, then building them is as simple as a for loop. Have look at the > > > way kernel-image-i386 is built if you don't understand what I'm talking > > > about. > > > > Not everyone has a quad-Athlon 1.4GhZ. Some of us have to deal with > > shit-slow machines. On which 14 builds take a very, very long time. > > Who says you have to compile debian packages on only machines you own? So tell elmo to get me through, and not, not do anything for 2 months. The only other faster machines I have access to, run RedHat or Mandrake, and I can't afford anything better for at least one or two months' time. -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED]
Re: kernel-{image,headers} package bloat breaks module builders
Previously Daniel Stone wrote: > Linux Kernel Developer I love this.. the only mention of 'daniel.*stone' in the entire kernel is a trivial patch to drivers/sound/sb_card.c.. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: kernel-{image,headers} package bloat breaks module builders
On Wed, 25 Apr 2001, Daniel Stone wrote: > On Wed, Apr 25, 2001 at 09:15:09AM +1000, Herbert Xu wrote: > > I think your concerns are not well-founded. If you have a sane build > > system, then building them is as simple as a for loop. Have look at the > > way kernel-image-i386 is built if you don't understand what I'm talking > > about. > > Not everyone has a quad-Athlon 1.4GhZ. Some of us have to deal with > shit-slow machines. On which 14 builds take a very, very long time. Who says you have to compile debian packages on only machines you own?
Re: kernel-{image,headers} package bloat breaks module builders
On Wed, Apr 25, 2001 at 10:31:06AM +1000, Daniel Stone wrote:
> On Wed, Apr 25, 2001 at 09:15:09AM +1000, Herbert Xu wrote:
> > I think your concerns are not well-founded. If you have a sane build
> > system, then building them is as simple as a for loop. Have look at the
> > way kernel-image-i386 is built if you don't understand what I'm talking
> > about.
>
> Not everyone has a quad-Athlon 1.4GhZ. Some of us have to deal with
> shit-slow machines. On which 14 builds take a very, very long time.
Where did you get the number 14? The current number of flavours is 8.
Besides, which module package is so big that compiling it takes a very
very long time?
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 05:26:27PM -0700, Aaron Lehmann wrote:
>
> Ok, so why did this come up at all in the discussion of the kernel
> package bloat? It seems to me that providing optimized kernels is a
Because someone asked why the kernel-headers necessary. Their presence
allows both our module maintainers and other maintainers to compile modules
easily. It doesn't mean that they will. But it certainly makes it a lot
more likely.
> after seeing so many kernel versions. Your binary module argument
> would support encouraging the use of a uniform kernel build. I don't
> care about this particular argument or its consequences, but I would
> think that you would, with your sympathies to "binary-only" kernel
> modules.
You seem to be confusing the kernel-header discussion with the kernel-image
discussion. Please go back and reread the thread.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: kernel-{image,headers} package bloat breaks module builders
On Wed, Apr 25, 2001 at 09:15:09AM +1000, Herbert Xu wrote: > I think your concerns are not well-founded. If you have a sane build > system, then building them is as simple as a for loop. Have look at the > way kernel-image-i386 is built if you don't understand what I'm talking > about. Not everyone has a quad-Athlon 1.4GhZ. Some of us have to deal with shit-slow machines. On which 14 builds take a very, very long time. -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED]
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 09:47:14AM +1000, Herbert Xu wrote: > No, but they can at least compile one for i386 easily as we're providing > matching kernel-headers. You're in exactly the same situation > (i.e., without binary modules) anyway if you compile your own kernel so > IMHO it's a moot point. Ok, so why did this come up at all in the discussion of the kernel package bloat? It seems to me that providing optimized kernels is a liability in this case since distributors of non-free no-source kernel modules will not compile a version against each possible kernel. In fact, they're much more likely to throw up their hands in disgust after seeing so many kernel versions. Your binary module argument would support encouraging the use of a uniform kernel build. I don't care about this particular argument or its consequences, but I would think that you would, with your sympathies to "binary-only" kernel modules.
Re: kernel-{image,headers} package bloat
Michael Stone <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 25, 2001 at 09:19:29AM +1000, Herbert Xu wrote:
>> I'm actually referring to all binary modules. But for binary-only modules
>> in particular, since you don't have the luxuary of being able to recompile
>> them, it's even more important to supply the builder with enough information
>> assuming that they're willing to compile it for your specifications.
> and asking them to compile a dozen different versions makes things
> better for binary module distributors?
No, but they can at least compile one for i386 easily as we're providing
matching kernel-headers. You're in exactly the same situation
(i.e., without binary modules) anyway if you compile your own kernel so
IMHO it's a moot point.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 04:32:03PM -0700, Aaron Lehmann wrote:
>
> But if I could ask a favor from you, why don't you post a list of
> affected files, and hopefully some description of these and why they
> are changed? There seems to be much confusion about the differences
I won't bore everyone here with it. The files are basically everything
under modules/ and config/. If you really want to find out, I've placed
a diff.bz2 at
http://gondor.apana.org.au/~herbert/kernel-headers.diff.bz2
This is a result a diff -urN between the plain kernel-headers and
kernel-headers-686.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 09:17:35AM +1000, Herbert Xu wrote: > > One file, composing of a few kilobytes, is an autogenerated header > > consisting of #define correctives enumerating the configuration. > > I think it's fairly clear that you were trying suggest that this is the > ONLY difference between these packages. You are wrong. Please quit wasting your time postulating what I was "trying" to suggest, and read my mail messages literally. But if I could ask a favor from you, why don't you post a list of affected files, and hopefully some description of these and why they are changed? There seems to be much confusion about the differences between the kernel-headers packages. I'm sure it would work towards clearing up these misconceptions. Many people (including me) have asked what these differences are, and now you're telling us to diff the patches. That's fair, but since you seem to think you know what differences there are you could save us all a lot of time by telling us what the differences are rather than sending us all on individual quests to download packages and seek these differences. I think we would all appreciate the favor.
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 09:19:29AM +1000, Herbert Xu wrote: > I'm actually referring to all binary modules. But for binary-only modules > in particular, since you don't have the luxuary of being able to recompile > them, it's even more important to supply the builder with enough information > assuming that they're willing to compile it for your specifications. and asking them to compile a dozen different versions makes things better for binary module distributors? -- Mike Stone
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 04:10:51PM -0700, Aaron Lehmann wrote:
>
> "Binary-only" is a misnomer, since one could translate them to ASCII
> or EBDIC if they wanted to. I'm not quite sure whether you're
> describing non-free kernel modules or kernel modules distributed in
> precompiled form (or both of the above). There's no reason to put up
> with either.
I'm actually referring to all binary modules. But for binary-only modules
in particular, since you don't have the luxuary of being able to recompile
them, it's even more important to supply the builder with enough information
assuming that they're willing to compile it for your specifications.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 04:14:18PM -0700, Aaron Lehmann wrote:
> On Wed, Apr 25, 2001 at 09:06:21AM +1000, Herbert Xu wrote:
> > Bullshit. Why don't you do a diff instead of talking about something that
> > you have no idea about?
>
> Do you deny that the file named autoconf.h contains precicely what I
> suggested? I did not attempt to present an exhaustive description of
> the differences between the various kernel-headers packages, which I
> indeed do not know in their entirety and had inquired about in a
> previous message in this thread. Instead, I presented Craig with a
> desceription of one (and the foremost, AFAIK) of the files that
> differs in the kernel-headers packages.
Sounds nice. But let's have a look at what you actually said:
> > so, what's the difference between all the packages? they're the same
> > header files from the same kernel source tree, aren't they?
>
> One file, composing of a few kilobytes, is an autogenerated header
> consisting of #define correctives enumerating the configuration.
I think it's fairly clear that you were trying suggest that this is the
ONLY difference between these packages.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: kernel-{image,headers} package bloat breaks module builders
On Tue, Apr 24, 2001 at 03:34:40PM -0400, Sam Hartman wrote:
>
> placed by this scheme. My assumption is that there will be different
> modversions for each kernel configuration and that as such, I will
That's correct.
> then my module-specific concerns go away. Even if you accept that the
> bandwith usage/mirror load/distribution size increase simply from the
> kernel packages is acceptable, it is not clear that multiplying the
Which I is think is the case.
> number of packages (and thus to an extent some size multiplier) by the
> number of module packages is also acceptable. Assuming that the
> number of module packages no in the kernel continues to increase,
> which I think likely, the problem will only get worse over time.
I doubt the increase is going to be that significant. Since most of these
will eventually become part of the mainstream kernel or get dropped.
> I also am concerned about the amount of work this creates for module
> maintainers. Now I have to rebuild a lot of packages both when my
I think your concerns are not well-founded. If you have a sane build
system, then building them is as simple as a for loop. Have look at the
way kernel-image-i386 is built if you don't understand what I'm talking
about.
> trees to satisfy make-kpkg), configure the kernel trees, which
> involves grabbing the configs from somewhere (either kernel images or
> the source package) and build modules for each kernel image.
If your module source is properly constructed, you should be able to get
away with a build-depends on the appropriate kernel-headers.
> The binary modules packages (alsa and pcmcia) especially although I
> haven't been doing much better of late tend to have an annoying
> history of not being in sync with the kernel. I'm concerned that this
I think part of the reason of them being out of sync is the way that they're
currently built. This is also partly a result of not having corresponding
kernel-headers as these module packages then try to use the kernel-source
+ the config file directly which either means a lot of work for the
maintainer to track them down or even worse, you end up with module packages
that don't work with the kernels.
I'm happy to answer questions about how the kernel-headers can be used to
make this process easier.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 09:06:21AM +1000, Herbert Xu wrote: > Bullshit. Why don't you do a diff instead of talking about something that > you have no idea about? Do you deny that the file named autoconf.h contains precicely what I suggested? I did not attempt to present an exhaustive description of the differences between the various kernel-headers packages, which I indeed do not know in their entirety and had inquired about in a previous message in this thread. Instead, I presented Craig with a desceription of one (and the foremost, AFAIK) of the files that differs in the kernel-headers packages. As many people have pointed out, you ought to read messages before replying to them. If this doesn't help, meditate on their messages.
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 09:05:42AM +1000, Herbert Xu wrote: > On Tue, Apr 24, 2001 at 02:10:48PM -0700, Aaron Lehmann wrote: > > If they're binary-only, I doubt much compilation will be necessary. > > They don't just come out of nowhere you know... "Binary-only" is a misnomer, since one could translate them to ASCII or EBDIC if they wanted to. I'm not quite sure whether you're describing non-free kernel modules or kernel modules distributed in precompiled form (or both of the above). There's no reason to put up with either.
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 02:14:40PM -0700, Aaron Lehmann wrote:
> On Wed, Apr 25, 2001 at 12:33:25AM +1000, Craig Sanders wrote:
> > On Tue, Apr 24, 2001 at 07:30:47PM +1000, Herbert Xu wrote:
> > >
> > > Kernel-headers-2.4.2 is built with the default config file, and the
> > > other ones are built with their respective config files.
> >
> > so, what's the difference between all the packages? they're the same
> > header files from the same kernel source tree, aren't they?
>
> One file, composing of a few kilobytes, is an autogenerated header
> consisting of #define correctives enumerating the configuration.
Bullshit. Why don't you do a diff instead of talking about something that
you have no idea about?
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 02:10:48PM -0700, Aaron Lehmann wrote:
> On Tue, Apr 24, 2001 at 08:01:39PM +1000, Herbert Xu wrote:
> > So that they can compile them? If you don't understand why we should do
> > that, then there's no point in us two arguing about it.
>
> If they're binary-only, I doubt much compilation will be necessary.
They don't just come out of nowhere you know...
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 12:33:25AM +1000, Craig Sanders wrote:
> On Tue, Apr 24, 2001 at 07:30:47PM +1000, Herbert Xu wrote:
> >
> > Kernel-headers-2.4.2 is built with the default config file, and the
> > other ones are built with their respective config files.
>
> so, what's the difference between all the packages? they're the same
> header files from the same kernel source tree, aren't they?
I seem to be repeating myself. Because all the config files are different,
the module checksums are different, as are everthing under include/config.
Anyway, why don't you just do a diff instead of wasting my time?
>"it's only one kernel, one source tree...so where do all these
> different header files come from? what's the point of them? what do
> they provide that just plain kernel-headers-2.4.2 doesn't provide?"
I think I've answered these questions enough times in a day. Please reread
my messages if you still don't understand.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[offtopic] Re: kernel-{image,headers} package bloat
On 24 Apr 2001, zhaoway wrote: > Your point is ridiculous. You think linux kernel compiling is > something as fundmental as tying shoelaces. rotfl. sorry. If tying shoelaces was so easy, then why do we have velco shoes?
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 07:30:47PM +1000, Herbert Xu wrote: > On Tue, Apr 24, 2001 at 08:47:44AM +1000, Craig Sanders wrote: > > > > what is the DIFFERENCE between kernel-headers-2.4.2 and all the other > > 2.4.2 kernel headers packages? > > Kernel-headers-2.4.2 is built with the default config file, and the > other ones are built with their respective config files. > > > why are they needed? > > For module builders. I develop/maintain several packages that compile kernel modules outside the kernel source, and understand a lot about what is necessary to compile modules outside the kernel. I have yet to see a header package in any distro that is actually useful in doing non-trivial module compilation -- there's just too much in the kernel that building modules _could_ depend on, such as including Makefile fragments, .config, scripts/makedep, etc. Right now, the rift between what is neccessary (for me) and what is available is so large that I always recommend to people to build their own kernel, even if it is a standard configuration. I'd be willing to help, since I think it is a good goal, but I think this thread is worthless. dave...
Re: kernel-{image,headers} package bloat
On Tue, 24 Apr 2001, Aaron Lehmann wrote: > On Tue, Apr 24, 2001 at 07:27:42PM +1000, Herbert Xu wrote: > > In any case, binary modules are a fact of life I'm afraid. > > Bull. We are Debian, not fucking RedHat or Mandrake. We strive to > exist without non-free software and using its existance as an excuse > to make your packages far worse is a complete disgrace to the project. > > Linus doesn't support binary-only modules. He doesn't care about them. > That's why they break. This attitude is good. We should ignore > non-free software, or at least not give it enough attention to let it > hurt the quality of our free software packages. Your "we should ignore non-free software" sounds as if you disagree with the Social Contract? <-- snip --> We acknowledge that some of our users require the use of programs that don't conform to the Debian Free Software Guidelines. ... Thus, although non-free software isn't a part of Debian, we support its use, and we provide infrastructure (such as our bug-tracking system and mailing lists) for non-free software packages. <-- snip --> cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 12:33:25AM +1000, Craig Sanders wrote: > On Tue, Apr 24, 2001 at 07:30:47PM +1000, Herbert Xu wrote: > > On Tue, Apr 24, 2001 at 08:47:44AM +1000, Craig Sanders wrote: > > > what is the DIFFERENCE between kernel-headers-2.4.2 and all the other > > > 2.4.2 kernel headers packages? > > > > Kernel-headers-2.4.2 is built with the default config file, and the > > other ones are built with their respective config files. > > so, what's the difference between all the packages? they're the same > header files from the same kernel source tree, aren't they? One file, composing of a few kilobytes, is an autogenerated header consisting of #define correctives enumerating the configuration.
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 08:01:39PM +1000, Herbert Xu wrote: > So that they can compile them? If you don't understand why we should do > that, then there's no point in us two arguing about it. If they're binary-only, I doubt much compilation will be necessary.
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 07:27:42PM +1000, Herbert Xu wrote: > In any case, binary modules are a fact of life I'm afraid. Bull. We are Debian, not fucking RedHat or Mandrake. We strive to exist without non-free software and using its existance as an excuse to make your packages far worse is a complete disgrace to the project. Linus doesn't support binary-only modules. He doesn't care about them. That's why they break. This attitude is good. We should ignore non-free software, or at least not give it enough attention to let it hurt the quality of our free software packages.
Re: kernel-{image,headers} package bloat breaks module builders
[I'm responding to Herbert directly to draw attention to this question and make sure I get a response from him. I have also read the rest of this thread even though I am responding to a fairly early message. ] I'm approaching this as the maintainer of the openafs package, which has a kernel module. I suspect other module package maintainers (PCMCIA, ALSA, etc) will have similar issues. I am concerned about the work that this new kernel image organization may create as well as the additional load on the mirrors potentially placed by this scheme. My assumption is that there will be different modversions for each kernel configuration and that as such, I will need to build binary modules packages against each kernel image. If you can guarantee that this is not the case and will not be the case, then my module-specific concerns go away. Even if you accept that the bandwith usage/mirror load/distribution size increase simply from the kernel packages is acceptable, it is not clear that multiplying the number of packages (and thus to an extent some size multiplier) by the number of module packages is also acceptable. Assuming that the number of module packages no in the kernel continues to increase, which I think likely, the problem will only get worse over time. I also am concerned about the amount of work this creates for module maintainers. Now I have to rebuild a lot of packages both when my upstream sources change and when the kernel images change. I had to do this already, but the effort involved is significantly less. I now have to look and make sure the set of images hasn't changed, retrieve the sources (kernel headers packages don't look enough like source trees to satisfy make-kpkg), configure the kernel trees, which involves grabbing the configs from somewhere (either kernel images or the source package) and build modules for each kernel image. The binary modules packages (alsa and pcmcia) especially although I haven't been doing much better of late tend to have an annoying history of not being in sync with the kernel. I'm concerned that this could make things worse. Personally as a user (who has used stock kernel images wherever possible) I'd much rather have modules packages that work than lots of kernel images to choose from.
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 12:36:17AM +1000, Craig Sanders wrote: > On Sun, Apr 22, 2001 at 09:18:33AM -0500, Adam Heath wrote: > > [...good stuff deleted...] > > > > Now, it doesn't take a genius, to see how this will cascade. > > > > [...more good stuff deleted...] > > > > The best way to handle all this, is to train users how to compile a kernel, > > or, let them pick the optimization they want, and we compile the kernel for > > them. > > well said. couldn't agree more. I could disagree pretty heavily by pointing that this would be shit as it would add an hour to the install. Why not just provide a stock i386 kernel and let people compile it later on? Some people need to patch in mm/swap patches, netfilter patches, their own hacks, etc, etc. -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED]
Re: kernel-{image,headers} package bloat
On Sun, Apr 22, 2001 at 09:18:33AM -0500, Adam Heath wrote: > [...good stuff deleted...] > > Now, it doesn't take a genius, to see how this will cascade. > > [...more good stuff deleted...] > > The best way to handle all this, is to train users how to compile a kernel, > or, let them pick the optimization they want, and we compile the kernel for > them. well said. couldn't agree more. craig -- craig sanders <[EMAIL PROTECTED]> GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 07:30:47PM +1000, Herbert Xu wrote: > On Tue, Apr 24, 2001 at 08:47:44AM +1000, Craig Sanders wrote: > > > > what is the DIFFERENCE between kernel-headers-2.4.2 and all the other > > 2.4.2 kernel headers packages? > > Kernel-headers-2.4.2 is built with the default config file, and the > other ones are built with their respective config files. so, what's the difference between all the packages? they're the same header files from the same kernel source tree, aren't they? > > and while you're at it, how about answering the other questions that > > you ignored in my last message? > > Which were? "it's only one kernel, one source tree...so where do all these different header files come from? what's the point of them? what do they provide that just plain kernel-headers-2.4.2 doesn't provide?" craig -- craig sanders <[EMAIL PROTECTED]> GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 10:39:14PM +1000, Herbert Xu wrote: > On Tue, Apr 24, 2001 at 10:34:24PM +1000, Daniel Stone wrote: > > > Oddly enough, I now *start* to see his point. BTW, I have neither the time > > (p100 with 48meg? multiple kernel builds, each time you build the package, > > and that's bound to be a few, because of testing?) or the space (multiple > > kernel trees, multiple kernel compiles, on 3.3gig?) to really do this, but > > I'll try anyway. > > Hmm, well since you were talking about kernel-headers, you don't have to > build any kernels. Besides, if you start off with the current kerne-image > source package, you'll see that it uses cp -l so it won't take up much more > space than one kernel source would. > > Just change the rules to not call make-kpkg build and make-kpkg kernel-image > and you're set. I'll do this. Now I'm off to make this patch of yours. Which I'm doing, because you're the best package maintainer in the world. Wait, huh? Now *there's* a logic flaw. And I'm definitely doing it. So I can see which side of the argument's right. -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK--
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 10:34:24PM +1000, Daniel Stone wrote:
> Oddly enough, I now *start* to see his point. BTW, I have neither the time
> (p100 with 48meg? multiple kernel builds, each time you build the package,
> and that's bound to be a few, because of testing?) or the space (multiple
> kernel trees, multiple kernel compiles, on 3.3gig?) to really do this, but
> I'll try anyway.
Hmm, well since you were talking about kernel-headers, you don't have to
build any kernels. Besides, if you start off with the current kerne-image
source package, you'll see that it uses cp -l so it won't take up much more
space than one kernel source would.
Just change the rules to not call make-kpkg build and make-kpkg kernel-image
and you're set.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 10:30:22PM +1000, Herbert Xu wrote: > On Tue, Apr 24, 2001 at 10:27:18PM +1000, Daniel Stone wrote: > > > > No argument there, but this is where necessity and duplication comes into > > play. These documentation packages, don't have 14 copies of the same file > > now, do they? > > Well, why don't you start writing a patch? And please submit the bug against > the right package, i.e., work out who's constructing what before you go off > filing bugs. I would be doing something productive [i.e. that patch] right now, if this thread weren't wasting my time. Oddly enough, I now *start* to see his point. BTW, I have neither the time (p100 with 48meg? multiple kernel builds, each time you build the package, and that's bound to be a few, because of testing?) or the space (multiple kernel trees, multiple kernel compiles, on 3.3gig?) to really do this, but I'll try anyway. -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED]
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 10:27:18PM +1000, Daniel Stone wrote:
>
> No argument there, but this is where necessity and duplication comes into
> play. These documentation packages, don't have 14 copies of the same file
> now, do they?
Well, why don't you start writing a patch? And please submit the bug against
the right package, i.e., work out who's constructing what before you go off
filing bugs.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 10:20:33PM +1000, Herbert Xu wrote: > On Tue, Apr 24, 2001 at 10:14:12PM +1000, Daniel Stone wrote: > > > > Let me restate the facts. Again. Very slowly. > > > > ftp.au.debian.org was broken. > > mirror.aarnet.edu.au was broken. > > Both of the above had outdated packages, for their Packages file. > > The kernel packages take up 110meg. > > More megabytes, more stress. > > More stress, more chance of breaking. > > Why don't you mail these site's admins and find out the real reason of them > breaking rather than guessing? So, you're telling me, that there's no way that the unnecessary duplication of kernel headers, in stressing mirrors, storage, and bandwidth more, contributed to this out-of-syncness? Put it this way: If we had 7000 1k packages, there would be virtually no breakages. If we had 7000 10meg packages, however, then you start to run into problems. You see? > > It's simple. You create a monster like this, you are helping (read: helping. > > not solely causing. helping. don't misquote me yet again) to create more > > stress on mirrors. Which makes them more likely to break. Like ftp.au.d.o > > and mirror.aarnet for the last 3 days (finally fixed tonight). > > It's hardly the biggest package directory in Debian. With the latest > version, it's even smaller than a few documentation packages. No argument there, but this is where necessity and duplication comes into play. These documentation packages, don't have 14 copies of the same file now, do they? -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK--
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 10:14:12PM +1000, Daniel Stone wrote:
>
> Let me restate the facts. Again. Very slowly.
>
> ftp.au.debian.org was broken.
> mirror.aarnet.edu.au was broken.
> Both of the above had outdated packages, for their Packages file.
> The kernel packages take up 110meg.
> More megabytes, more stress.
> More stress, more chance of breaking.
Why don't you mail these site's admins and find out the real reason of them
breaking rather than guessing?
> It's simple. You create a monster like this, you are helping (read: helping.
> not solely causing. helping. don't misquote me yet again) to create more
> stress on mirrors. Which makes them more likely to break. Like ftp.au.d.o
> and mirror.aarnet for the last 3 days (finally fixed tonight).
It's hardly the biggest package directory in Debian. With the latest
version, it's even smaller than a few documentation packages.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 10:07:03PM +1000, Herbert Xu wrote: > On Tue, Apr 24, 2001 at 10:02:54PM +1000, Daniel Stone wrote: > > > > > That's not what you were claiming though. You said: > > > > > > > The thing is, by including all these headers, you're helping break > > > > stuff for > > > > everyone. But you're also helping a small percentage of people who don't > > > > How the bloody hell is this a contradiction? > > > > This is NOT. A. CONTRADICTION. > > Did I say you were contradicting yourself? I was merely pointing out that > you were making false claims. No, these are entirely true. You know why? Because I had to put off my dist-upgrade for 3 days because ftp.au.d.o and aarenet (the latter, as usual), were both broken. That is not in *any* way false. > Let me help you with your logic. You said two things here: > > 1. ... you're helping break stuff for everyone > > 2. ONE HUNDRED AND TEN MEGABYTES PER KERNEL RELEASE DOES NOT HELP MIRRORS > WHICH HAVE ... > > Somehow I don't see how 2 has got anything to do with 1. Let me restate the facts. Again. Very slowly. ftp.au.debian.org was broken. mirror.aarnet.edu.au was broken. Both of the above had outdated packages, for their Packages file. The kernel packages take up 110meg. More megabytes, more stress. More stress, more chance of breaking. Have you understood yet? It's simple. You create a monster like this, you are helping (read: helping. not solely causing. helping. don't misquote me yet again) to create more stress on mirrors. Which makes them more likely to break. Like ftp.au.d.o and mirror.aarnet for the last 3 days (finally fixed tonight). The appropriate bug has been filed. -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK--
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 10:02:54PM +1000, Daniel Stone wrote:
>
> > That's not what you were claiming though. You said:
> >
> > > The thing is, by including all these headers, you're helping break stuff
> > > for
> > > everyone. But you're also helping a small percentage of people who don't
>
> How the bloody hell is this a contradiction?
>
> This is NOT. A. CONTRADICTION.
Did I say you were contradicting yourself? I was merely pointing out that
you were making false claims.
Let me help you with your logic. You said two things here:
1. ... you're helping break stuff for everyone
2. ONE HUNDRED AND TEN MEGABYTES PER KERNEL RELEASE DOES NOT HELP MIRRORS WHICH
HAVE ...
Somehow I don't see how 2 has got anything to do with 1.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 09:33:52PM +1000, Herbert Xu wrote: > On Tue, Apr 24, 2001 at 08:45:11PM +1000, Daniel Stone wrote: > > On Tue, Apr 24, 2001 at 08:20:43PM +1000, Herbert Xu wrote: > > > > > > FUD. Show me what's actually broken. > > > > Mirrors. Slow. Out-of-sync. > > It's still FUD until you produce the evidence that it's caused by the kernel > images. I never said "caused". I said that the kernel mirrors were only excaberating a problem. Stop being a nit-picking smartarse and dodging my questions. > > > Prove that it is caused by the kernel images and I'll get rid of them. > > > > So, are you trying to tell me, that the extra ONE HUNDRED AND TEN MEGABYTES, > > is HELPING?!? > > That's not what you were claiming though. You said: > > > The thing is, by including all these headers, you're helping break stuff for > > everyone. But you're also helping a small percentage of people who don't How the bloody hell is this a contradiction? This is NOT. A. CONTRADICTION. Let me be entirely clear on this. ONE HUNDRED AND TEN MEGABYTES PER KERNEL RELEASE DOES NOT HELP MIRRORS WHICH HAVE OUT OF SYNC PACKAGES FILES AND ACTUAL PACKAGES HALF THE TIME. So far, you have yet to prove me wrong. Show me HOW the HELL an extra 110meg HELPS these poor, generally crippled, mirrors (btw, ftp.au.d.o is now fixed, probably just took a while to snarf all those kernel-* packages), and I will STFU. Until then, you've been dodging my question. ANSWER IT. -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK--
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 08:45:11PM +1000, Daniel Stone wrote:
> On Tue, Apr 24, 2001 at 08:20:43PM +1000, Herbert Xu wrote:
> >
> > FUD. Show me what's actually broken.
>
> Mirrors. Slow. Out-of-sync.
It's still FUD until you produce the evidence that it's caused by the kernel
images.
> > Prove that it is caused by the kernel images and I'll get rid of them.
>
> So, are you trying to tell me, that the extra ONE HUNDRED AND TEN MEGABYTES,
> is HELPING?!?
That's not what you were claiming though. You said:
> The thing is, by including all these headers, you're helping break stuff for
> everyone. But you're also helping a small percentage of people who don't
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 08:20:43PM +1000, Herbert Xu wrote: > Daniel Stone <[EMAIL PROTECTED]> wrote: > > > The thing is, by including all these headers, you're helping break stuff for > > everyone. But you're also helping a small percentage of people who don't > > FUD. Show me what's actually broken. Mirrors. Slow. Out-of-sync. > > ftp.au.d.o is currently missing several packages, as is > > mirror.aarnet.edu.au. Breaks a dist-upgrade (out-of-sync Packages, and > > actual packages). > > Prove that it is caused by the kernel images and I'll get rid of them. So, are you trying to tell me, that the extra ONE HUNDRED AND TEN MEGABYTES, is HELPING?!? -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK--
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 08:21:28PM +1000, Herbert Xu wrote: > On Tue, Apr 24, 2001 at 08:18:42PM +1000, Daniel Stone wrote: > > > > I can understand why you might say that that's a valid point, but IMHO, we > > shouldn't fuck up current users (by overloading mirrors), just so we can > > support LAZY users to compile something THAT IS NOT EVEN IN DEBIAN. > > Do you actually have any hard facts regarding mirrors broken by kernel > images or do you just like spreading FUD? ftp.au.d.o and mirror.aarnet.edu.au, the only two Australian Debian mirrors I know, currently have out-of-sync sid Packages and actual packages. Obviously this isn't directly caused by the kernel sources, but the extra load does *not* help one iota. -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK--
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 08:18:42PM +1000, Daniel Stone wrote:
>
> I can understand why you might say that that's a valid point, but IMHO, we
> shouldn't fuck up current users (by overloading mirrors), just so we can
> support LAZY users to compile something THAT IS NOT EVEN IN DEBIAN.
Do you actually have any hard facts regarding mirrors broken by kernel
images or do you just like spreading FUD?
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: kernel-{image,headers} package bloat
Daniel Stone <[EMAIL PROTECTED]> wrote:
> The thing is, by including all these headers, you're helping break stuff for
> everyone. But you're also helping a small percentage of people who don't
FUD. Show me what's actually broken.
> ftp.au.d.o is currently missing several packages, as is
> mirror.aarnet.edu.au. Breaks a dist-upgrade (out-of-sync Packages, and
> actual packages).
Prove that it is caused by the kernel images and I'll get rid of them.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 08:01:39PM +1000, Herbert Xu wrote: > On Tue, Apr 24, 2001 at 08:00:01PM +1000, Daniel Stone wrote: > > If we don't distribute them, why in hell are we breaking mirrors by > > supporting them? Sounds dodgy to me. > > So that they can compile them? If you don't understand why we should do > that, then there's no point in us two arguing about it. I can understand why you might say that that's a valid point, but IMHO, we shouldn't fuck up current users (by overloading mirrors), just so we can support LAZY users to compile something THAT IS NOT EVEN IN DEBIAN. -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK--
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 07:49:48PM +1000, Herbert Xu wrote: > On Tue, Apr 24, 2001 at 07:47:48PM +1000, Daniel Stone wrote: > > > > They still suck, and they're still non-free. > > Who said that we were going to distribute them? If we don't distribute them, why in hell are we breaking mirrors by supporting them? Sounds dodgy to me. -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK--
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 07:50:34PM +1000, Herbert Xu wrote: > On Tue, Apr 24, 2001 at 07:49:45PM +1000, Daniel Stone wrote: > > > > If you're including the entire headers in every package, this is an awful > > fallacy. Why not just do something like this: > > kernel-headers-2.4.3-common: all the 2.4.3 headers > > kernel-headers-2.4.3-piii: autoconf.h and modules/ for p3 > > kernel-headers-2.4.3-k7: autoconf.h and modules/ for athlon > > etc, etc. > > and then, have kernel-headers-2.4.3-piii depend on > > kernel-headers-2.4.3-common? > > How about providing a patch? You claim to be a Kernel Developer, so you > should know the rules. I am a kernel developer, in my spare time, which is very scarce these days. Obviously, hacking on Netfilter, is different from hacking on kernel packages. I'll have a crack at it tonight, if you're happy. But remember: * I'm still learning my way around Debian packaging, * My machine is slow as all hell (the good old p100 with 48meg of ram absolutely *slogs* through any kernel build, let alone SEVERAL), * I don't have a lot of time, and I have homework to do. -- Daniel Stone Linux Kernel Developer, in his spare time [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK--
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 08:00:01PM +1000, Daniel Stone wrote:
> On Tue, Apr 24, 2001 at 07:49:48PM +1000, Herbert Xu wrote:
>
> > Who said that we were going to distribute them?
>
> If we don't distribute them, why in hell are we breaking mirrors by
> supporting them? Sounds dodgy to me.
So that they can compile them? If you don't understand why we should do
that, then there's no point in us two arguing about it.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
