Bug#43787: changed title, and remade the proposed change
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
Reply to: