Debian Bug report logs - #43787
[AMENDED 07/09/1999] policy on -g, a proposal

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Ben Collins <bcollins@debian.org>

To: submit@bugs.debian.org

Subject: [PROPOSAL] changing policy on compiling with -g .. a better way

Date: Mon, 30 Aug 1999 18:25:52 -0400

Package: policy

As a buildd admin, I want to congratulate the original policy on all the wasted
cpu cycles it has cost my system by forcing packages to compile with -g even
though those same binaries will be stripped later of this costly debugging
information.

Now, what I want to propose, is not a change so much as an ammendment. Keep the
policy there (which is meant to make it easier to build binaries and libraries
with debugging information), but add an ammendment for this situation:

--------
The package can by default build without -g if it also provides a mechanism
to easily be rebuilt with debugging information. This can be done by providing
a "build-debug" make target, or allowing the user to specify "BUILD_DEBUG=yes"
in the environment while compiling that package.
--------

Now this has several added benefits:

1) It is actually easier to build debugging bins and libraries this way (no more
   editing debian/rules or similar) since it provides a documented way of getting
   this type of build.
2) There will be much less wasted cpu time for the autobuilders since not having
   debugging information (and hence also not having to strip it) will increase
   the speed of compiles. This skips an entire pass of the compiler, iirc


Please, I would simply like to get a second on this and have it voted on or
whatever it is that we do with policy proposals now-a-days. Then added to policy.
I don't want to argue over the ten million technical points, and considering this
is very unobtrusive, and allows the maintainer to choose (not force) whether or
not to abide by it, it shouldn't provide much flame material, nor extensive
discussion about the pro's and con's.

Thanks,
  Ben


--  
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Message #14 received at 43787@bugs.debian.org (full text, mbox, reply):

From: Manoj Srivastava <srivasta@debian.org>

To: 43787@bugs.debian.org

Subject: Re: [PROPOSAL] changing policy on compiling with -g .. a better way

Date: 01 Sep 1999 15:42:07 -0500

Hi,

        This is the final form (or, at least, I am done with this). I
 am forwarding this to bugs.debian.org

        manoj

        The minimal change:
======================================================================
          CC = gcc
          CFLAGS = -O2 -g -Wall # sane warning options vary between programs
          LDFLAGS = # none
          install -s # (or use strip on the files in debian/tmp)
...

          The `-g' flag is useful on compilation so that you have available a
          full set of debugging symbols in your built source tree, in case
          anyone should file a bug report involving (for example) a core dump.
+         Alternately, you could use an environment variable
+         BUILD_OPTIONS, which, if it contains `debug', would cause
+         compilation to be done with -g. (Remember not to call
+         ``install -s'' or strip on the binaries afterwards for this
+         case). The resulting binaries in your built package will then
+         contain the full set of debugging symbols (remember not to call 
+         ``install -s'' or ``strip'' on the binaries afterwards). 
+
+          This would let us later add other options in a fairly clean way.
+
+         Additionally, (and optionally) you may also provide a target
+         `build-debug' in debian/rules which has the same effect as
+         setting BUILD_OPTIONS to  contain `debug'. This can be done 
+         quite simply, with the folowing lines:
+ build-debug: BUILD_OPTIONS+=debug
+ build-debug: build
+        Note: You still have to ensure that BUILD_OPTIONS is honoured.
======================================================================

        The second way: we don't just offer an alternative, we
 deprecate the old method, but let it be still legal.
======================================================================
          CC = gcc
-         CFLAGS = -O2 -g -Wall # sane warning options vary between programs
+         # sane warning options vary between programs
+         CFLAGS = -O2 -Wall
+         ifneq (,$(findstring $(BUILD_OPTIONS),DEBUG Debug debug))
+         CFLAGS += -g 
+         INSTALL_FLAGS= -s
+         endif
          LDFLAGS = # none
-         install -s # (or use strip on the files in debian/tmp)
+         install $(INSTALL_FLAGS) # 
...

          
          The `-g' flag is useful on compilation so that you have available a
          full set of debugging symbols in your built source tree, in case
          anyone should file a bug report involving (for example) a core dump.
+         It is acceptable, but deprecated, to always have -g in
+         ``CFLAGS'', and ``use install -s'' to install binaries or use
+         ``strip'' on the binaries in debian/tmp, but that make it
+         hard to create a debuggable debian package, and increase
+         build time for all builds, since debugging information is
+         created and then stripped away. The preferred method is to
+         use an environment variable BUILD_OPTIONS, which, if it 
+         contains `debug', would cause compilation to be done with -g. The
+         resulting binaries in your package will then contain the full
+         set of debugging symbols (remember not to call ``install -s''
+         or ``strip'' on the binaries afterwards). 
+
+          This would let us later add other options in a fairly clean way.
+
+         Additionally, (and optionally) you may also provide a target
+         `build-debug' in debian/rules which has the same effect as
+         setting BUILD_OPTIONS to contain `debug'. This can be done 
+         quite simply, with the folowing lines:
+ build-debug: BUILD_OPTIONS+=debug
+ build-debug: build
======================================================================

-- 
 INSIDE, I have the same personality disorder as LUCY RICARDO!!
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Message #19 received at 43787@bugs.debian.org (full text, mbox, reply):

From: Ben Collins <bcollins@debian.org>

To: 43787@bugs.debian.org

Subject: Re: Bug#43787: [PROPOSAL] changing policy on compiling with -g .. a better way

Date: Wed, 1 Sep 1999 16:30:26 -0400

Ok, reformated Manoj's great work. Only change being DEB_BUILD_OPTIONS
instead of just BUILD_OPTIONS.

I wondered if anyone else has an opionion on which of these to choose.
Either one works for me, but I think the first one is probably needed
since some builds just can't be changed sensibly.

Ben

======================================================================
  The minimal change
======================================================================
          CC = gcc
          CFLAGS = -O2 -g -Wall # sane warning options vary between programs
          LDFLAGS = # none
          install -s # (or use strip on the files in debian/tmp)
...

          The `-g' flag is useful on compilation so that you have available a
          full set of debugging symbols in your built source tree, in case
          anyone should file a bug report involving (for example) a core dump.
+         Alternately, you could use an environment variable
+         DEB_BUILD_OPTIONS, which, if it contains `debug', would cause
+         compilation to be done with -g. (Remember not to call
+         ``install -s'' or strip on the binaries afterwards for this
+         case). The resulting binaries in your built package will then
+         contain the full set of debugging symbols (remember not to call 
+         ``install -s'' or ``strip'' on the binaries afterwards). 
+
+          This would let us later add other options in a fairly clean way.
+
+         Additionally, (and optionally) you may also provide a target
+         `build-debug' in debian/rules which has the same effect as
+         setting DEB_BUILD_OPTIONS to  contain `debug'. This can be done 
+         quite simply, with the folowing lines:
+ build-debug: DEB_BUILD_OPTIONS+=debug
+ build-debug: build
+        Note: You still have to ensure that DEB_BUILD_OPTIONS is honoured.
======================================================================

        The second way: we don't just offer an alternative, we
 deprecate the old method, but let it be still legal.
======================================================================
          CC = gcc
-         CFLAGS = -O2 -g -Wall # sane warning options vary between programs
+         # sane warning options vary between programs
+         CFLAGS = -O2 -Wall
+         ifneq (,$(findstring $(DEB_BUILD_OPTIONS),DEBUG Debug debug))
+         CFLAGS += -g 
+         INSTALL_FLAGS= -s
+         endif
          LDFLAGS = # none
-         install -s # (or use strip on the files in debian/tmp)
+         install $(INSTALL_FLAGS) # 
...

          
          The `-g' flag is useful on compilation so that you have available a
          full set of debugging symbols in your built source tree, in case
          anyone should file a bug report involving (for example) a core dump.
+         It is acceptable, but deprecated, to always have -g in
+         ``CFLAGS'', and ``use install -s'' to install binaries or use
+         ``strip'' on the binaries in debian/tmp, but that make it
+         hard to create a debuggable debian package, and increase
+         build time for all builds, since debugging information is
+         created and then stripped away. The preferred method is to
+         use an environment variable DEB_BUILD_OPTIONS, which, if it 
+         contains `debug', would cause compilation to be done with -g. The
+         resulting binaries in your package will then contain the full
+         set of debugging symbols (remember not to call ``install -s''
+         or ``strip'' on the binaries afterwards). 
+
+          This would let us later add other options in a fairly clean way.
+
+         Additionally, (and optionally) you may also provide a target
+         `build-debug' in debian/rules which has the same effect as
+         setting DEB_BUILD_OPTIONS to contain `debug'. This can be done 
+         quite simply, with the folowing lines:
+ build-debug: DEB_BUILD_OPTIONS+=debug
+ build-debug: build
======================================================================

Message #26 received at 43787@bugs.debian.org (full text, mbox, reply):

From: Manoj Srivastava <srivasta@debian.org>

To: 43787@bugs.debian.org, control@bugs.debian.org

Subject: Re: consensus on debug (-g) policy

Date: 05 Sep 1999 22:07:19 -0500

retitle 43787 [AMENDMENT 05/09/1999] Compiling with debugging symbols
thanks

Hi,

        I would prefer this version (which is the one discussed, and
 which has a blurb for a specific package removed). Arguably, this is
 the version on which a consensus was achieved.

        Additionally, the paragraph removed had commentary on the
 current shortcomings of the specific package under consideration,
 which does not belong i technical policy either.

        If people think that a blurb for any specific helper package
 should be included in the technical policy (which I think is a bad
 idea), they can come up with an independent proposal to add such a
 paragraph.

        manoj

======================================================================
        We deprecate the old method, but let it be still legal.
======================================================================
          CC = gcc
-         CFLAGS = -O2 -g -Wall # sane warning options vary between programs
+         # sane warning options vary between programs
+         CFLAGS = -O2 -Wall
+         ifneq (,$(findstring $(DEB_BUILD_OPTIONS),DEBUG Debug debug))
+         CFLAGS += -g 
+         INSTALL_FLAGS= -s
+         endif
          LDFLAGS = # none
-         install -s # (or use strip on the files in debian/tmp)
+         install $(INSTALL_FLAGS) # 
.........
          The `-g' flag is useful on compilation so that you have available a
          full set of debugging symbols in your built source tree, in case
          anyone should file a bug report involving (for example) a core dump.
+         It is acceptable, but deprecated, to always have -g in
+         ``CFLAGS'', and use ``install -s'' to install binaries or use
+         ``strip'' on the binaries in debian/tmp, but that make it
+         hard to create a debuggable debian package, and increase
+         build time for all builds, since debugging information is
+         created and then stripped away. The preferred method is to
+         use an environment variable DEB_BUILD_OPTIONS, which, if it 
+         contains `debug', would cause compilation to be done with -g. The
+         resulting binaries in your package will then contain the full
+         set of debugging symbols (remember not to call ``install -s''
+         or ``strip'' on the binaries afterwards).
+
+
+         The DEB_BUILD_OPTIONS var will also let us later add other options in
+         a fairly clean way.
+
+         Additionally, (and optionally) you may also provide a target
+         `build-debug' in debian/rules which has the same effect as
+         setting DEB_BUILD_OPTIONS to contain `debug'. This can be done 
+         quite simply, with the following lines:
+ build-debug: DEB_BUILD_OPTIONS+=debug
+ build-debug: build
======================================================================
-- 
 The most merciful thing in the world ... is the inability of the
 human mind to correlate all its contents. Lovecraft
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Message #39 received at 43787@bugs.debian.org (full text, mbox, reply):

From: Ben Collins <bcollins@debian.org>

To: control@bugs.debian.org

Cc: 43787@bugs.debian.org

Subject: changed title, and remade the proposed change

Date: Tue, 7 Sep 1999 08:24:06 -0400

[Message part 1 (text/plain, inline)]

retitle 43787 [AMENDED 07/09/1999] policy on -g, a proposal

thanks

Ok, this is my last attempt for a crowd pleaser. This new an improved
proposal should satisfy any and all complaints (as few as they were). This
new proposal has several added features.

1) Raul was correct in that policy does nto require -g, but it does
suggest it in a major way. So this proposal takes away that huge
suggestion.

2) This proposal gives a suggestion on how to implement the ability to
setup you package to be built with debugging intact, it does not require
this feature.

3) The best part is that most programs that depend on debhelper's dh_strip
will automatically follow this suggestion (except that they will always
build with -g, but atleast it's possible to get non-stripped packages for
custom builds).

This is a non-imposing, non-package-changing-required proposal. I surely
hope that there would be no technical reason to not allow a better
"suggestion" in the policy.

Attached are two files. One containing the current context of this
section (Section 4.1 of the policy manual, version 3.0.1.1). The seconds
is the proposed context. You can diff the two, in order to see what is
changed.

Ben

[current (text/plain, attachment)]

[proposed (text/plain, attachment)]

Message #46 received at 43787@bugs.debian.org (full text, mbox, reply):

From: Raul Miller <raul@usatoday.com>

To: Ben Collins <bcollins@debian.org>, 43787@bugs.debian.org

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

Date: Tue, 7 Sep 1999 10:59:08 -0400

On Tue, Sep 07, 1999 at 08:24:06AM -0400, Ben Collins wrote:
> Ok, this is my last attempt for a crowd pleaser. This new an improved
> proposal should satisfy any and all complaints (as few as they were).
> This new proposal has several added features.

I still think this makes the whole recommendation much more
complicated to implement.

Let's assume that you care to keep executables with debugging
symbols around.  In that case, the old recommendation would
have you build the package once.  The new recommendation
would have you compile twice.  Time saved?

Let's assume that you don't care to keep executables with
debugging symbols around.  In that case, you compile without
-g -- end of story.

So this proposal is aimed at people who want to have both options, near
as I can tell -- and even here, it's for people who don't want to edit
any files (either putting -g into a makefile, or perhaps something like
specifying CC as a shell script which does /usr/bin/gcc -g "$@").

I think a simple sentence indicating that -g is really optional would
be fine.  Perhaps:


*** 2017,2023 ****
            <prgn>install</prgn>, or by calling <prgn>strip</prgn> on
            the binaries after they have been copied into
            <tt>debian/tmp</tt> but before the tree is made into a
!           package.</p>
            
          <p>
            The <tt>-g</tt> flag is useful on compilation so that you
--- 2017,2024 ----
            <prgn>install</prgn>, or by calling <prgn>strip</prgn> on
            the binaries after they have been copied into
            <tt>debian/tmp</tt> but before the tree is made into a
!           package.  Note that binaries must be stripped even if
!           they were compiled without -g.</p>
            
          <p>
            The <tt>-g</tt> flag is useful on compilation so that you

-- 
Raul

Message #51 received at 43787@bugs.debian.org (full text, mbox, reply):

From: Ben Collins <bcollins@debian.org>

To: Raul Miller <raul@usatoday.com>

Cc: 43787@bugs.debian.org

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

Date: Tue, 7 Sep 1999 09:24:34 -0400

On Tue, Sep 07, 1999 at 10:59:08AM -0400, Raul Miller wrote:
> On Tue, Sep 07, 1999 at 08:24:06AM -0400, Ben Collins wrote:
> > Ok, this is my last attempt for a crowd pleaser. This new an improved
> > proposal should satisfy any and all complaints (as few as they were).
> > This new proposal has several added features.
> 
> I still think this makes the whole recommendation much more
> complicated to implement.

Well I think your personal opinion is just aimed at making this all more
difficult. Since this isn't a technical objection, I surely hope that it
is not considered a "non-consensus" issue. Speaking opinionatedly, I could
say that %99 of policy makes things more complicated (not that I do, but
as an example). This doesn't make any of it less relevant or note worthy.

> Let's assume that you care to keep executables with debugging
> symbols around.  In that case, the old recommendation would
> have you build the package once.  The new recommendation
> would have you compile twice.  Time saved?

Then you ignore the suggestion...case closed.

> Let's assume that you don't care to keep executables with
> debugging symbols around.  In that case, you compile without
> -g -- end of story.

And the same with this proposal...your points are equally applicable to
the current state and my proposed state, so I fail to see your argument as
anything other than misdirected rants.

> So this proposal is aimed at people who want to have both options, near
> as I can tell -- and even here, it's for people who don't want to edit
> any files (either putting -g into a makefile, or perhaps something like
> specifying CC as a shell script which does /usr/bin/gcc -g "$@").

The proposal is aimed at giving a better way of getting debuggable
packages, and yes it's nice for the maintainer to go through the trouble
of setting this up themselves, IF they want to. The main case being to
clear up the misconception that -g is a suggested CFLAG, but in this case,
we also give a clear and standard suggestion on setting up this ability in
the build (not to mention building the package with debuggable binaries
aswell) if the maintainer wishes to.

> I think a simple sentence indicating that -g is really optional would
> be fine.  Perhaps:

I think you are being over simplified with this. Even with this proposal,
you are free to enable -g as you see fit in your package. Just because you
don't see the benefits of this change, doesn't make it less useful or
important. I don't have to prove it's usefulness to %100 of the developers
(since not all of policy is useful to all developers anyway), so as far as
I am concerned this is an opinion issue, not a technical objection.

Ben

Message #56 received at 43787@bugs.debian.org (full text, mbox, reply):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>

To: Ben Collins <bcollins@debian.org>, 43787@bugs.debian.org

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

Date: Tue, 7 Sep 1999 18:44:55 +0200

On Tue, Sep 07, 1999 at 08:24:06AM -0400, Ben Collins wrote:
> 
> Ok, this is my last attempt for a crowd pleaser.

I hope not.

> This new an improved
> proposal should satisfy any and all complaints (as few as they were). This
> new proposal has several added features.

Unfortunately, I dislike the wording in the new proposal.

> If you want users to be able
> to rebuild your package with debugging information easily, the suggested
> way is to use the ``DEB_BUILD_OPTIONS'' environment variable.

This is way to weak, IMHO. First, I think as many packages as possible
should allow for this feature, so it should not be "if you want users to be
able", but: "if it is possible to build the program with debugging
information", so that I have the policy behind me if I file a bug report
which implements this change in a package. So, this feature should be
optional but strongly recommended.

Second, _if_ package implements the feature, it must do it by parsing the
DEB_BUILD_OPTIONS variable, or we will never get consistency at all. Hence,
I think the "the suggested way" is much too weak in this context.

> In order to retain this information in the custom built package, the
> binaries should not be stripped (either with "install -s" or using the
> strip program).

First, who says that we talk about binaries? Can we find a more general term
like "object files"? There are also libraries...

Then, the object files must not be stripped. Again, should seems to be too
weak.

> NOTE: This should not be how the package is built by
> default, it is merely for convenience to users wishing to debug the
> programs in the package, or for you as the maintainer to find problems
> when bugs are filed against the package.

I think this note is unnecessary and can be deleted without substitute.
 
The rest is fine.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org  Check Key server 
Marcus Brinkmann              GNU    http://www.gnu.org    for public PGP Key 
Marcus.Brinkmann@ruhr-uni-bochum.de                        PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/

Message #61 received at 43787@bugs.debian.org (full text, mbox, reply):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>

To: Ben Collins <bcollins@debian.org>, 43787@bugs.debian.org

Subject: Re: Bug#43787: alternate proposal (was: changed title...)

Date: Fri, 10 Sep 1999 04:28:08 +0200

Hello,

I have written down what I think to be a better proposal, which is based on
Bens but ended up a bit more concise ;). However, I am not asking for seconds.

I hope nobody is offended by this, I just try to be more constructive and
productive. I see considerable progress in this discussion, and I hope Ben
does bear with the -policy crew just a little bit longer :).

This proposal does contain an important bug fix (In you proposal Ben, it
needs to be ifneq instead ifeq). Also, by rearranging the findstring
options, we can check more than one field in DEB_BUILD_OPTIONS.

This latter feature is used to introduce a new string "nostrip" to address
Rauls concern.

Last but not least, the wording is different. It says:
"It is recommended to support building the package with debugging information
 through the following interface:"

This is of course what I asked for. I believe this wording still allows for
a lot of packages to not implement this feature either because "debug" does
not apply to them or because it is too hard to implement.

I believe that the wording, if carefully read, does not make any packages
instantly "buggy". I also believe that it does allow for packages to
implement other interfaces to switch on debugging information along the
default interface DEB_BUILD_OPTIONS. I also believe it allows for extension
It is flexible (because you can choose between no debug information, debug
information, and debug information plus not stripping to build debug
packages).

I think it is therefore a bit better than the current version. Please
comment on this, especially if you find yourself in disagreement with parts
of this draft.

Ben, can we work towards a common proposal?

Thank you,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org  Check Key server 
Marcus Brinkmann              GNU    http://www.gnu.org    for public PGP Key 
Marcus.Brinkmann@ruhr-uni-bochum.de                        PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/

Message #66 received at 43787@bugs.debian.org (full text, mbox, reply):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>

To: Ben Collins <bcollins@debian.org>, 43787@bugs.debian.org

Subject: Re: Bug#43787: well, here it is: alternate proposal (was: changed title...)

Date: Fri, 10 Sep 1999 04:48:39 +0200

On Fri, Sep 10, 1999 at 04:28:08AM +0200, Marcus Brinkmann wrote:
> 
> I have written down what I think to be a better proposal

Of course, because I am utterly stupid, I forgot to attach the beast.

--- policy.sgml.old	Fri Sep 10 03:45:13 1999
+++ policy.sgml	Fri Sep 10 04:10:28 1999
@@ -1966,13 +1966,13 @@
 	    Generally the following compilation parameters should be used:
 	    <example>
 	      CC = gcc 
-	      CFLAGS = -O2 -g -Wall # sane warning options vary between programs 
+	      CFLAGS = -O2 -Wall # sane warning options vary between programs 
 	      LDFLAGS = # none 
 	      install -s # (or use strip on the files in debian/tmp)
 	    </example></p>
 	    
 	  <p>
-	    Note that all installed binaries should be stripped,
+	    Note that by default all installed binaries should be stripped,
 	    either by using the <tt>-s</tt> flag to
 	    <prgn>install</prgn>, or by calling <prgn>strip</prgn> on
 	    the binaries after they have been copied into
@@ -1980,16 +1980,35 @@
 	    package.</p>
 	    
 	  <p>
-	    The <tt>-g</tt> flag is useful on compilation so that you
-	    have available a full set of debugging symbols in your
-	    built source tree, in case anyone should file a bug report
-	    involving (for example) a core dump.</p>
-	    
-	  <p>
 	    The <tt>-N</tt> flag should not be used.  On a.out systems
 	    it may have been useful for some very small binaries, but
 	    for ELF it has no good effect.</p>
-	    
+
+	  <p>
+	    It is recommended to support building the package with
+	    debugging information through the following interface:
+	    If the environment variable <tt>DEB_BUILD_OPTIONS</tt>
+	    contains the string <tt>debug<tt>, compile the software with
+	    debugging information (usually this involves adding the
+	    <tt>-g</tt> flag to <tt>CFLAGS</tt>). This allows to generate
+	    a build tree with debugging information. If the environment
+	    variable <tt>DEB_BUILD_OPTIONS</tt> contains the
+	    string <tt>nostrip</tt>, do not strip the files at installation
+	    time. This allows to generate a package with debugging
+	    information included. The following makefile snippet
+	    is only an example how to test for either condition:
+
+	    <example>
+	      CFLAGS = -O2 -Wall
+	      INSTALL = install
+	      ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
+		CFLAGS += -g
+	      endif
+	      ifneq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
+		INSTALL += -s
+	      endif
+	    </example></p>
+
 	  <p>
 	    It is up to the package maintainer to decide what
 	    compilation options are best for the package.  Certain

--  
`Rhubarb is no Egyptian god.' Debian http://www.debian.org  Check Key server 
Marcus Brinkmann              GNU    http://www.gnu.org    for public PGP Key 
Marcus.Brinkmann@ruhr-uni-bochum.de                        PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/

Message #71 received at 43787@bugs.debian.org (full text, mbox, reply):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>

To: Raul Miller <raul@usatoday.com>, 43787@bugs.debian.org

Subject: Re: Bug#43787: well, here it is: alternate proposal (was: changed title...)

Date: Fri, 10 Sep 1999 15:04:22 +0200

Hi,

Raul suggested to mention core dumps, which is indeed a good idea.
I extended this to give a general rationale for debugging symbols.

I suggest the following wording. Raul, does this cover what you head in
mind? if not, can you alternate it and suggest a different wording?

Replace:

+	    It is recommended to support building the package with
+	    debugging information through the following interface:

with:

+           Debugging symbols are useful for error diagnosis, investigation
+           of core dumps (which may be submitted by users in bug reports),
+           or testing and developing the software. Therefore it is
+           recommended to support building the package with
+           debugging information through the following interface:

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org  Check Key server 
Marcus Brinkmann              GNU    http://www.gnu.org    for public PGP Key 
Marcus.Brinkmann@ruhr-uni-bochum.de                        PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/

Message #76 received at 43787@bugs.debian.org (full text, mbox, reply):

From: Ben Collins <bcollins@debian.org>

To: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>, 43787@bugs.debian.org

Cc: Raul Miller <raul@usatoday.com>

Subject: Re: Bug#43787: well, here it is: alternate proposal (was: changed title...)

Date: Fri, 10 Sep 1999 09:56:24 -0400

I don't mind this proposal as long as it satisfies everyone. I'll redo mine
to match Marcus's suggested one if I don't hear any complaints.

Something like this for the options?:

------------------
CFLAGS	:= -O2
INSTALL	:= install -s

ifneq (,$(findstring $(DEB_BUILD_OPTIONS),debug))
  CFLAGS += -g
  ifneq (,$(findstring $(DEB_BUILD_OPTIONS),nostrip))
    INSTALL := install
  endif
endif
------------------

I set it up this way, because I don't think a `nostrip' is pertinent unless
building with `debug' also. In this way "DEB_BUILD_OPTIONS=nostrip" will not
do anything, but "DEB_BUILD_OPTIONS='debug nostrip'" will have the desired
affect.

Ben

Message #81 received at 43787@bugs.debian.org (full text, mbox, reply):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>

To: Ben Collins <bcollins@debian.org>, 43787@bugs.debian.org

Cc: Raul Miller <raul@usatoday.com>

Subject: Re: Bug#43787: well, here it is: alternate proposal (was: changed title...)

Date: Sat, 11 Sep 1999 02:17:42 +0200

On Fri, Sep 10, 1999 at 09:56:24AM -0400, Ben Collins wrote:
> I don't mind this proposal as long as it satisfies everyone. I'll redo mine
> to match Marcus's suggested one if I don't hear any complaints.

Thanks for your positive response. I hope people speak up if they have
complaints, so they can (hopefully) be addressed.

> Something like this for the options?:
> 
> ------------------
> CFLAGS	:= -O2
> INSTALL	:= install -s
> 
> ifneq (,$(findstring $(DEB_BUILD_OPTIONS),debug))

Note that this does not work, because findstring does search the first
string in the second. So you have to use 

ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))

>   CFLAGS += -g
>   ifneq (,$(findstring $(DEB_BUILD_OPTIONS),nostrip))

Same here of course.

>     INSTALL := install
>   endif
> endif
> ------------------
> 
> I set it up this way, because I don't think a `nostrip' is pertinent unless
> building with `debug' also. In this way "DEB_BUILD_OPTIONS=nostrip" will not
> do anything, but "DEB_BUILD_OPTIONS='debug nostrip'" will have the desired
> affect.

Well, I thought about it but didn't saw a reason not to support a single
nostrip (without debug). However, I don't really care either way.
(I don't think it is a bug to strip if only "nostrip" is given, on the oher
hand, I can't think of a good reason to do that, too.) i would like to hear
other peoples opinion on that.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org  Check Key server 
Marcus Brinkmann              GNU    http://www.gnu.org    for public PGP Key 
Marcus.Brinkmann@ruhr-uni-bochum.de                        PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/

Message #86 received at 43787@bugs.debian.org (full text, mbox, reply):

From: Steve Greenland <stevegr@debian.org>

To: 43787@bugs.debian.org

Subject: Re: Bug#43787: well, here it is: alternate proposal (was: changed title...)

Date: Sat, 11 Sep 1999 14:45:50 -0500

On 10-Sep-99, 08:04 (CDT), Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> wrote: 
> 
> Hi,
> 
> Raul suggested to mention core dumps, which is indeed a good idea.
> I extended this to give a general rationale for debugging symbols.

[*snip* of suggested wording]

While I don't feel a real strong objection, I don't think this kind of
stuff (rationale) belongs in the standard. It's already wordy enough.

Steve

Message #91 received at 43787@bugs.debian.org (full text, mbox, reply):

From: Ben Collins <bcollins@debian.org>

To: Steve Greenland <stevegr@debian.org>, 43787@bugs.debian.org

Subject: Re: Bug#43787: well, here it is: alternate proposal (was: changed title...)

Date: Sat, 11 Sep 1999 13:00:42 -0400

On Sat, Sep 11, 1999 at 02:45:50PM -0500, Steve Greenland wrote:
> On 10-Sep-99, 08:04 (CDT), Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> wrote: 
> > 
> > Hi,
> > 
> > Raul suggested to mention core dumps, which is indeed a good idea.
> > I extended this to give a general rationale for debugging symbols.
> 
> [*snip* of suggested wording]
> 
> While I don't feel a real strong objection, I don't think this kind of
> stuff (rationale) belongs in the standard. It's already wordy enough.
> 
> Steve

I'de rather it be more on the "wordy" side than have developers saying "now
why in the hello do they want me to do that!?"

Ben

Message #96 received at 43787@bugs.debian.org (full text, mbox, reply):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>

To: Steve Greenland <stevegr@debian.org>, 43787@bugs.debian.org

Subject: Re: Bug#43787: well, here it is: alternate proposal (was: changed title...)

Date: Sun, 12 Sep 1999 02:44:30 +0200

On Sat, Sep 11, 1999 at 02:45:50PM -0500, Steve Greenland wrote:
> On 10-Sep-99, 08:04 (CDT), Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> wrote: 
> > 
> > Hi,
> > 
> > Raul suggested to mention core dumps, which is indeed a good idea.
> > I extended this to give a general rationale for debugging symbols.
> 
> [*snip* of suggested wording]
> 
> While I don't feel a real strong objection, I don't think this kind of
> stuff (rationale) belongs in the standard. It's already wordy enough.

Well, it is not without precedence. For a lot of things in the policy, we
also give the rationale behind it.

I think it only appears wordy because the DEB_BUILD_OPTIONS syntax is
explained at lengths. I hope that someday we will find more uses of it
(special optimization... whatever else), and then this is moved to another
section or so, and we will only have a reference in this chapter ("...if
`debug' is specified in DEB_BUILD_OPTIONS" point).

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org  Check Key server 
Marcus Brinkmann              GNU    http://www.gnu.org    for public PGP Key 
Marcus.Brinkmann@ruhr-uni-bochum.de                        PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/

Message #101 received at 43787@bugs.debian.org (full text, mbox, reply):

From: Steve Greenland <stevegr@debian.org>

To: 43787@bugs.debian.org

Subject: Re: Bug#43787: well, here it is: alternate proposal (was: changed title...)

Date: Sat, 11 Sep 1999 20:12:10 -0500

On 11-Sep-99, 19:44 (CDT), Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> wrote: 
> > While I don't feel a real strong objection, I don't think this kind of
> > stuff (rationale) belongs in the standard. It's already wordy enough.
> 
> Well, it is not without precedence. For a lot of things in the policy, we
> also give the rationale behind it.
> 
> I think it only appears wordy because the DEB_BUILD_OPTIONS syntax is
> explained at lengths.

Sorry, I should have quoted exactly what I was (mildly) objecting to:
The three line "why debugging symbols are good" paragraph. I'm happy
with the rest of the proposal.

Message #106 received at 43787@bugs.debian.org (full text, mbox, reply):

From: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>

To: 43787@bugs.debian.org, bcollins@debian.org

Subject: Bug#43787: [PROPOSAL] changing policy on compiling with -g .. a better way

Date: Tue, 26 Oct 1999 00:36:19 +0100 (BST)

I'm not quite clear from the bug logs what the final agreed wording is
for this proposal.  Please could you let me know?

   Julian

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
        Debian GNU/Linux Developer,  see http://www.debian.org/~jdg

Message #111 received at 43787@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joey@kitenet.net>

To: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>, 43787@bugs.debian.org

Cc: bcollins@debian.org

Subject: Re: Bug#43787: PROPOSAL] changing policy on compiling with -g .. a better way

Date: Tue, 26 Oct 1999 21:51:05 -0700

Julian Gilbey wrote:
> I'm not quite clear from the bug logs what the final agreed wording is
> for this proposal.  Please could you let me know?

I don't know that we ever reached a consensus on this proposal. Or rather we
almost did, and then it devolved into many little arguments.

-- 
see shy jo

Message #116 received at 43787@bugs.debian.org (full text, mbox, reply):

From: Ben Collins <bcollins@debian.org>

To: Joey Hess <joey@kitenet.net>

Cc: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>, 43787@bugs.debian.org, bcollins@debian.org

Subject: Re: Bug#43787: PROPOSAL] changing policy on compiling with -g .. a better way

Date: Wed, 27 Oct 1999 07:00:55 -0400

On Tue, Oct 26, 1999 at 09:51:05PM -0700, Joey Hess wrote:
> Julian Gilbey wrote:
> > I'm not quite clear from the bug logs what the final agreed wording is
> > for this proposal.  Please could you let me know?
> 
> I don't know that we ever reached a consensus on this proposal. Or rather we
> almost did, and then it devolved into many little arguments.

I will accumulate all the facts and post a final proposal based on notes
of everyones opinions. I'll try to have it by this evening (EDT).

Ben

Message #127 received at 43787-done@bugs.debian.org (full text, mbox, reply):

From: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>

To: 15709-done@bugs.debian.org, 17369-done@bugs.debian.org, 22935-done@bugs.debian.org, 29522-done@bugs.debian.org, 39398-done@bugs.debian.org, 40934-done@bugs.debian.org, 43787-done@bugs.debian.org, 51091-done@bugs.debian.org, 52225-done@bugs.debian.org, 53405-done@bugs.debian.org, 53755-done@bugs.debian.org, 53756-done@bugs.debian.org, 53757-done@bugs.debian.org, 53758-done@bugs.debian.org, 53760-done@bugs.debian.org, 53761-done@bugs.debian.org, 53762-done@bugs.debian.org, 53763-done@bugs.debian.org, 54777-done@bugs.debian.org, 56407-done@bugs.debian.org, 56692-done@bugs.debian.org, 58771-done@bugs.debian.org

Cc: srivasta@debian.org

Subject: Closed in debian-policy 3.2.0.0

Date: Wed, 2 Aug 2000 15:17:16 -0700

These bugs have been closed in policy version 3.2.0.0.

Thanks Manoj!

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
        Debian GNU/Linux Developer,  see http://www.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Send a report that this bug log contains spam.