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

Re: linux-image-*-dbg for squeeze?

My 2 cents being that I'm far from part of the kernel team:

Am Freitag 05 März 2010 00:40:27 schrieb John Wright:
> Hi kernel team,
> What would it take to get kernel debuginfo into squeeze?  As I
> understand it, the main blockers were [2]:
>  1) It would blow up the archive by ~10 GB
>      - This is a lot of space, but I believe it's worth it for crash
>        dump and systemtap support.
	Having these supported would be dead handy.
>  2) It would increase the buildd disk requirements as well.  Bastion
>     gave a 30 GB figure, given 8 flavors in a particular architecture.
	I would say even more than 30 GB since you neeed for each arch so many kernel
	flavours + matching modules to them afaik.
>      - Do we have that many flavors for any arch now?)
	Yes, I can remember 4 : VServer- , OpenVz- , Xen- , Standard- Kernel-Images.
	For these you need the drivers, the modules all build seperately and 
	against them.
	Then there are the whole bunch of different modules and packages that have 
	to hookinto a particular part of the Kernel(libnetfilter?). 
	Then there is the whole lot of patch sets, modules, source-packages.
	All in all ~30GB is a good rough estimate. 
>      - Do we have buildd's that are this low on disk space?  Couldn't we
>        upgrade them?
	You could donate disks if you want but I doubt that this solves the overall 
	problem. FTPMasters sure have a reason why they dont want so many flavours in
	their repos. 

> I haven't tried to see if my patch still applies against the current
> linux-2.6 packaging.  If I made sure it still worked (submitting a new
> patch if necessary, of course), would you consider accepting it?
IMHO If your patch still works you could package it as a deb and let people 
apply it to their kernel and recompile if they want to. 
In this case can you tell how big the package would be when you would make 
that for your patch?


Andreas Marschke.

PS: Just my 2 Cents...

Reply to: