Re: Bug#43787: changed title, and remade the proposed change

[Raul Miller <raul@usatoday.com>]

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