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 [EMAIL PROTECTED] PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
