On Tue, Sep 07, 1999 at 12:05:17PM +0200, Santiago Vila wrote:
> In my opinion, this exceptional measure should not last longer than one
> release, i.e. potato, or else the whole FHS transition will last
> much more than expected (the FHS transition will be "complete" when all
> docs are in /usr/
On Wed, Sep 08, 1999 at 08:32:16AM -0400, Ben Collins wrote:
> I have benchmarked this, and most of the larger packages (those that
> build several megs or more of object files, which with -g on, was quite a
> lot) saw a roughly 15% increase in speed during compiles. Now this is on a
> fast Ultra
On Wed, Sep 08, 1999 at 08:34:48AM -0400, Ben Collins wrote:
> And it seems this would be correct. For the user to have a debuggable
> package they must have downloaded the source and built it with
> DEB_BUILD_OPTIONS=debug. So it is safe to say that they _will_ have the
> source around.
Or the
Package: packaging-manual
Version: 3.0.1.1
Quoting from section 4.2.14:
stable
This is the current `released' version of Debian GNU/Linux. A new
version is released approximately every 3 months after the development
code has been frozen for a month of testing. Once the distribution is
stabl
On Wed, Sep 08, 1999 at 10:36:52AM -0400, Raul Miller wrote:
> On Wed, Sep 08, 1999 at 08:32:16AM -0400, Ben Collins wrote:
> > Raul, you seem to have no real interest in this proposal.
>
> I do have an interest -- I'm not concerned about the speed benefits,
> but I very much do have an interest.
Raul Miller wrote:
>
> On Wed, Sep 08, 1999 at 02:52:59PM +0200, Marcus Brinkmann wrote:
> > This is why I think a suggestion is too weak. You can equally well remove
> > the suggestion, because I can't rely on it and have to check always if a
> > package follows the policy suggestion or does it d
On Wed, Sep 08, 1999 at 08:32:16AM -0400, Ben Collins wrote:
> Raul, you seem to have no real interest in this proposal.
I do have an interest -- I'm not concerned about the speed benefits,
but I very much do have an interest.
In particular, I care about:
(1) impact on my packages,
(2) impact
On Wed, Sep 08, 1999 at 09:58:57AM -0400, Raul Miller wrote:
> > And, for debugging, you probably want the source environment around...
>
> This is fairly important: debugging is a manual process.
And it seems this would be correct. For the user to have a debuggable
package they must have downloa
On Wed, Sep 08, 1999 at 09:39:23AM -0400, Raul Miller wrote:
> ...Ben's proposal is purely an optimization. [I'm not sure if anyone
> has benchmarked it -- and while I hope someone cares about benchmarking
> optimizations, I don't care enough myself. My packages compile in a
> few seconds on the
On Wed, Sep 08, 1999 at 09:39:23AM -0400, Raul Miller wrote:
> You can always build with DEB_DEBUG_OPTIONS=debug and expect that the
> executables created will have debug symbols. This is already true even
> without this policy being implemented.
Correction: this is true for some packages now, a
On Wed, Sep 08, 1999 at 02:52:59PM +0200, Marcus Brinkmann wrote:
> This is why I think a suggestion is too weak. You can equally well remove
> the suggestion, because I can't rely on it and have to check always if a
> package follows the policy suggestion or does it differently.
No.
You can alwa
On Tue, Sep 07, 1999 at 03:14:56PM -0700, Chris Waters wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> > On Tue, Sep 07, 1999 at 01:11:33PM -0700, Chris Waters wrote:
> > > If the binaries can be debugged in the build directories, then there's
> > > little reason not to strip them.
>
> > T
On Tue, Sep 07, 1999 at 06:10:06PM -0400, Ben Collins wrote:
> What I mean by that is, if we just say that policy suggests building without
> -g, then some package maintainers _will_ implement a way of getting debuggable
> binaries (or objects as your may be). We want this implementation to stay
>
On Wed, Sep 08, 1999 at 07:07:15AM -0400, Raul Miller wrote:
> On Tue, Sep 07, 1999 at 09:37:19PM -0400, Ben Collins wrote:
> > Umm, how do you see your hack as a speed gain when it requires every
> > invocation of gcc to also invoke perl?!
>
> I guess that means you didn't read the rest of the me
On Wed, Sep 08, 1999 at 01:58:54PM +1000, Anthony Towns wrote:
> Huh? As in "Build-Depends: gcc (= 2.7.2)" ? How's this different to
> Bug#41232? Or, rather, how is Bug#41232 lacking?
Bug#41232 is good, though [to take the example from the most recent
message], I still don't see that specifying al
On Tue, Sep 07, 1999 at 09:37:19PM -0400, Ben Collins wrote:
> Umm, how do you see your hack as a speed gain when it requires every
> invocation of gcc to also invoke perl?!
I guess that means you didn't read the rest of the message.
It's trivial to rewrite in C, and I offered to do so.
> So you
On Tue, Sep 07, 1999 at 09:47:32PM -0400, Raul Miller wrote:
> In the long run, we need a decent source dependency system, which
> integrates well with the build environment. [I'm imagining something
> along the lines of bsd's .include designed for
> debian/rules, and a source dependency system t
On Tue, Sep 07, 1999 at 09:47:32PM -0400, Raul Miller wrote:
> On Tue, Sep 07, 1999 at 06:12:07PM -0400, Ben Collins wrote:
> > Umm, what about libraries that purposely compile -dbg packages? This
> > is a silly idea, it's not a good idea for the autobuilders to muck
> > around with the way the pac
On Tue, Sep 07, 1999 at 06:12:07PM -0400, Ben Collins wrote:
> Umm, what about libraries that purposely compile -dbg packages? This
> is a silly idea, it's not a good idea for the autobuilders to muck
> around with the way the package is meant to be built.
Good point.
Of course, this is solvable
On Tue, Sep 07, 1999 at 06:55:43PM -0400, Raul Miller wrote:
> On Tue, Sep 07, 1999 at 05:38:03PM +0200, Roman Hodek wrote:
> > You forgot the case of recompilations: If default is with -g + strip
> > (as policy currently recommends), a lot of time is wasted on the
> > auto-builder machines.
>
> I
On Tue, Sep 07, 1999 at 03:14:56PM -0700, Chris Waters wrote:
>
> If we (the project, not individual developers) are not going to
> distribute packages with debug info included, I see no reason for
> policy to concern itself with the requirement (or even recommendation)
> to make it possible to bu
Look guys, I have a responsibility to see that policy is right.
And so do you.
I understand that a number of you are more than a little hostile towards
the technical committee -- I'm guessing that you don't want some random
group stepping on your work.
But, for the immediate future it doesn't rea
22 matches
Mail list logo
