On Tue, Sep 07, 1999 at 06:12:07PM -0400, Ben Collins wrote: > Umm, what about libraries that purposely compile -dbg packages? This > is a silly idea, it's not a good idea for the autobuilders to muck > around with the way the package is meant to be built.
Good point. Of course, this is solvable -- for example, build those packages in a different autobuilder environment (perhaps make the cc cover sensitive to an environmental variable). This would make the autobuilders a bit more complicated -- but we are talking about optimizing the autobuilders, so that's probably ok. Also, this sort of implementation would yield a far greater speed improvement over the short run than your current policy proposal would. In the long run, we need a decent source dependency system, which integrates well with the build environment. [I'm imagining something along the lines of bsd's .include <bsd.whatever.mk> designed for debian/rules, and a source dependency system that lets you specify compiler versions or library versions independently from the target architecture.] If such a thing were designed/implemented/built/whatever, and if the package maintainers for the major build tools thought it was well put together, I'd support a policy change so that all new or editted packages would (at some point) be required to use/support this new system. But what you're doing right now: optimizing a hack... That's more likely to get in the way of the long term solution than anything else. [If we had a decent source dependency, etc. design I'm sure what you're proposing would fit right in -- with a few minor changes. But if we go ahead with the optimization when we're still at hack implementation stage we're asking for backwards compatability problems.] Some of your advice about the developer's options is good -- but that's more material for the packaging manual than for policy. And, of course, your original concept (that -g should be optional) was good -- but you'd already won that one before you even started. -- Raul
