dann frazier writes... > fyi, I have a patch to the kernel-image build system that would spit out > a separate package w/ a debug kernel image & module set under /usr/lib. > I did this in the 2.4.25 timeframe, and I was getting ~204M debug > packages per flavor. I don't know how big it would be for just the > image (no modules).
dannf, I assume "flavor" means each kernel-image source package and the various kernel-image packages it delivers? That seems like quite a burden for the archive. I can think of a couple ways to handle this, 1) implement debug packages in the packaging, but don't build them as part of the default build target. Put instructions in the source on which rule to use to build your own. The oprofile package could refer users to these. This would mean each user who wanted them would need to build them which sucks, but this is easily implemented. 2) If there was some way to put these in a part of the archive that is optional for mirroring, then the packages could still be built only once and the people who needed them could get them from this other location. At first I was thinking experimental, but since they would build from the same source that needs to go in unstable, this wouldn't work with out special ftp-master tricks. So what about the idea of a new section of the archive that stores all the debuggable stuff, these kernels and -dbg packages etc.? Since most users don't need debuggable stuff this seems like a natural way to split the archive for mirroring and cdimage purposes. This would be a nice solution to the problem but obviously would take more to implement. Just a crazy idea... -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
