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:48:48AM -0400, Ben Collins wrote:
> On Thu, Sep 09, 1999 at 08:14:36PM +0200, Marcus Brinkmann wrote:
> > On Thu, Sep 09, 1999 at 11:20:48AM -0400, Ben Collins wrote:
> > > "You have to implement debugging this way if you are going to
> > > support it". Two reasons:
> > > 
> > > 1) Right now policy does not require -g, but only suggests an
> > >    example, yet everyone is compilg this way. I don't think our
> > >    developers have to be forced into every possible detail of
> > >    packaging. Who knows, with the option to do it differently,
> > >    some one may find a better way. Also, with a suggest, you can
> > >    always file a wishlist bug to the affect if you want. So they
> > >    can support either form (their own and the suggested one in
> > >    policy).
> > 
> > Your proposal was concerned about autobuilders. It would be great to have an
> > autobuuilder someday which produces packages with debugging symbols. Only a
> > common interface can make this possible.
> 
> No my proposal is because of the autobuilder, not aimed at making it better.
> The point is to get out the -g suggestion from polic while still giving
> a prefered way of getting the debug info.

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.

> > Erm. _If_ you can support building with debugging information, you can
> > make it possible to activate it with parsing DEB_BUILD_OPTIONS.
> > How can this ever be not true? You can't think of an example because there
> > is non. Probalby you are misunderstanding what my preferred requirements
> > would be.
> 
> You don't know this for sure.

I do. If you can write a rules file to build with debugging symbols, you can
use this rules script when DEB_BUILD_OPTIONS is set to "debug". Always. If
you can write a rules file which compiles without debug symbols, you can
even make it possible to use it when "debug" is not set.

You just need a simple debian/rules file which parses DEB_BUILD_OPTIONS, and
source in the one file if debug is set and the other file if debug is not
set.

This is even a mathematical proof. I can formalize it for you if needed :)

> Sorry to see you take this to that extreme. I'm voicing my opinion. If I feel that
> there is speific agreement that it _should_ be forced instead of suggested, I'll be
> more than happy to comply and change the proposal. Right now, I don't see any agreement
> that this is what most want.

What I don't understand is what reason there are not to "enforce" it, because
you can always comply, there really isn't a problem, and it is opening the
door for a standard interface to pass build flags. OTOH, not enforcing it
has the chance that people will make up their own methods, and we missed a
way for standardization early on.

I had this problem with dpkg-architecture: Many packages used
"arch=$(shell dpkg-architecture)", which did sorta work until the Hurd port
came up. Despite the fact that "--print-architecture" is an undocumented
feature and not standardized at all. The result is that many rules script
use it, and those scripts are definitive broken on the Hurd. My
dpkg-arhcitetcure proposal fixes this situation by providing a standard
interface to get the build architecture and make it a requirement.
This is a big step forward.

In the same way I wanted to see this proposal progress. I was disappointed
seeing how little ambitious your proposal ended up to be.

> Let's see, I was rude to you how? Thanks for the civil reply.

Sorry, I was annoyed. At least I managed to flame without calling names :)

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/