> This approach still puts the load on the ftp mirrors and cdroms. I > don't know if it's worth in all but a few cases Well, it's not really worth it for programs that have no bugs. ;-) I do think that it would be a _real_ benefit to be able to instantly start debugging any app/library in the system with little or no fuss. How much of a benefit? I'm not sure. I don't think anybody has ever put together a complete OS debugging system where you can _quickly_ swap debugging code in/out depending on which package you need to debug. It does place extra load on the mirrors and cdroms though. That's why it ought to be debated. I wonder how much extra load though. Does debugging info compress well? What percentage of the archive is consumed by architecture-specific binaries? > (after all, it's *more* important to ship buildable sources.) Yes. I agree. But it's almost an impossible task because of the ever changing nature of the system. ie. I'm trying to debug dpkg, but first I've got to figure out how to build it - I think there is a newer version of automake that is causing me grief. The only way around this type of problem is to be constantly building the entire system all the time (the debian-autobuild concept) and catching bugs. We need source dependencies for that + other stuff too. The nice thing about shipping debug info is that we can debug even if we can't build. Plus, it's just a faster development cycle if you can debug first, then edit, then build. Many times, I end up debugging something, just to find out that "it's not a bug; it's a feature". Quite often, using gdb is the only way to truly understand how something works -- because the documentation doesn't, or can't, express it's behaviour well enough. Part of the reason I'm keen about this idea is because I'm working on (possibly) building a business around doing Debian support. If I can debug a problem in 5 minutes vs. 2 hours -- that's a big win. > Also, the approach you mention (standardizing on build/install/strip) > sounds like a reasonable extension to existing policy; a lot of > programs probably do it anyway, or at least do build/install-s, and > can just throw the -s into a make variable (or change $INSTALL to > "install --ignore-strip-arg" :-) I'd like to be able to control this from debian/rules. Hopefully this wouldn't be a big change. Cheers, - Jim
Attachment:
pgpdkz1ZsuGSn.pgp
Description: PGP signature