On Thu, Sep 09, 1999 at 08:42:18PM +0200, Marcus Brinkmann wrote: > Yes, and I acknowledge your goal. But I am concerned that people will just > drop the -g without replacement, and the rest choose the suggested way or > another. What I would like to see is to have some unified way to pass build > flags (such as "debug") to the rules file. The DEB_BUILD_OPTIONS seemed to > fit the bill, but only if people use it.
Consider defining two alternatives for debugging options (1) the current way (how you handle debugging is up to the maintainer, always strip executables, it's a good idea to build executables with debugging symbols for your own use), (2) and the new way (DEB_BUILD_OPTIONS=debug means you build a package with debugging symbols in the executables, without =debug you don't compile with -g and you strip the executables). In this fantasy, (1) would be depreciated. This seems overall like a decent plan, but there are a few cases I'd be concerned about: (a) Developer builds package, something gets upgraded on developer's (libc, gcc, whatever), an executable dumps core on client machine -- if developer didn't already build executable with debugging symbols that core dump is useless. (b) Developer builds package, then goes back again and builds package with debugging symbols turned on. Developer gets annoyed at the extra time this new and improved system incurrs. (c) Developer builds package and package with debugging symbols, but carelessly didn't upload the package without debugging symbols so the package with debugging symbols gets put in Incoming and propagated... Note that (a) and (c) are issues regardless of whether the new mechanism is mandantory. (b) is only an issue if the developer doesn't have the option of using the older mechanism. Personally, I'd recommend defining DEB_DEBUG_OPTION=debug-strip which would build with debugging symbols, but strip for package generation then strip. This alone would address most of (a) and (b). The only options I can think of for (c) are: don't use =debug or somehow rename the package at build time. -- Raul
