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

[Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>]

On Thu, Sep 09, 1999 at 11:32:17PM +1000, Anthony Towns wrote:
> On Thu, Sep 09, 1999 at 02:45:19PM +0200, Marcus Brinkmann wrote:
> > On Wed, Sep 08, 1999 at 09:24:06PM -0400, Raul Miller wrote:
> > > (2) You want some way to prevent the executables from being stripped
> > > before they're installed on the target system.  [Depreciating the current
> > > unconditional stripping of debugging symbols from packages.]
> > Yes. Along the same lines as (1).
> 
> Erm. I hope by this that you mean "encouraging everybody to make
> packages buildable either with or without debugging symbols", rather
> than "deprecating that packages be built without debugging symbols
> or stripped".

Yesofcourse. There was never contention about this particular point.

Perhaps I should say it again, in all clearness.

1. Packages should by default build without any debugging information, and
be stripped.

2. There should be a well defined interface (DEB_BUILD_OPTIONS?) to build
with debugging information and not strip the files. (Currently, there is
only a suggestion in Ben's proposal).

3. Packages are encouraged to support the interface in (2), but are not
strictly required to do so. Patches to support it should be accepted if they
don't have negative impact on the package by other means.

This does not make all packages buggy, because (3) allows for transition
time as long as required for each package individually. Similar to how
dpkg-architecture allows for individual transition time.

> > > Since Ben's proposal only touches on compilation -- not package building
> > > or installation -- you're only addressing (1) at the moment.
> 
> Erm, what?
> 
> To my understanding,
> 
> # DEB_BUILD_OPTIONS=debug debian/rules binary
> 
> will produce a .deb with full debugging information if the option's
> supported. In particular, consider the paragraph:
> 
> ] 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). 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.

Ah yes. Allright. But it still says "should", right? This means a package
maintainer can strip them and still comply with policy.

> Ben's found something he's happy with, thought it through and written a
> proposal. If you want something better, the onus is on you to come up with
> it, rather than demand that Ben satisfy your every whim. It'd be nice if
> you at least made a *guess* at what would work.

Yeah, it seems that I have to make another proposal which will likely change
Ben's proposal again to do it right. If this is the way to go, then it shall
be it. But I thought the discussion time was exactly for that: Finding out
how the proposal can be improved to hammer it in a good shape that will not
require fixing it afterwards. (In other words: There will be substantial
overlap between this fictional and Ben's proposal, and I really don't
understand why people prefer to have two seperate proposals that are very
similar instead one that's complete and perfect).

If Ben chooses not to change his proposal (which is his perfect right), I
withdraw my second, because the proposal does nothing to achieve the goal I
head in mind when reading it (the opposite is true).

> For example: "Well, we've got an options setting now, why don't we have,
> say:
> 
> 	debug	-- build with debugging information
> 	nostrip -- don't strip binaries
> 
> ? Then when you're building packages normally, you can have "debug"
> set in your environmnet, and get the current behaviour, and if you want
> debuggable binaries, you set "nostrip" as well."

Nono. A single "debug" option for this is fine. I was just forgetting about
that paragraph, sorry. I apologize.

> I think just a single "debug" option is more convenient, though,
> personally.

Agreed.
 
>  Also, I preferred the `stronger' proposals, that
> said "this is the way to go...... but if you really don't want to you
> don't have to".

Thanks. I hope you will then support the fictional proposal we mentioned
above when someone (probably me) comes around to submit it.

Thanks for your corrections,
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/