Debug packages policy?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Debug packages policy?

Christian Weisgerber
What's the policy for adding debug packages to ports?

Is the intend to add debug packages...
* eventually to all ports
or
* only to ports where they seem particularly useful?

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Debug packages policy?

Antoine Jacoutot-7
On Mon, Jan 20, 2020 at 11:31:11PM +0100, Christian Weisgerber wrote:
> What's the policy for adding debug packages to ports?
>
> Is the intend to add debug packages...
> * eventually to all ports
> or
> * only to ports where they seem particularly useful?

I think the policy is up for debate really.
Nothing has been decided yet.
My humble opinion is that "particularly useful" is subjective...

--
Antoine

Reply | Threaded
Open this post in threaded view
|

Re: Debug packages policy?

chohag
Antoine Jacoutot writes:

> On Mon, Jan 20, 2020 at 11:31:11PM +0100, Christian Weisgerber wrote:
> > What's the policy for adding debug packages to ports?
> >
> > Is the intend to add debug packages...
> > * eventually to all ports
> > or
> > * only to ports where they seem particularly useful?
>
> I think the policy is up for debate really.
> Nothing has been decided yet.
> My humble opinion is that "particularly useful" is subjective...

It would be more useful I think to make the ports and release build
processes more approachable so that debugging symbols can be made
available. If they need it, that is - I haven't had any real trouble
beyond locating the correct documents to read and fumbling my way
through.

The reason being that including debugging symbols means you're,
well, debugging. In the event that something bug-like is discovered
debugging symbols will certainly make the stack traces sent to
maintainers & developers more useful but a full OpenBSD build
environment *right there* makes it easier to fix the bug where it
was discovered and where that fix can be tested, resulting in not
only a patch, but a *working* patch.

When making things easier for people, I prefer to make it easier
for people to make my work easier, not make it easier for them to
just give me more work.

Perhaps the enormous packages could have debug-symbol-filled variants
but these days even that argument holds little water. I don't have
the numbers to hand but the things which have traditionally had the
worst build times - kernels, gcc, java, X, even firefox until they
brought rust in to repair that oversight - now have build times
measured in hours or minutes rather than weeks.

tl;dr: grep -ri strip /usr/share/mk and, yes, read. No ";dr" for you.

</tuppence>

Matthew

Reply | Threaded
Open this post in threaded view
|

Re: Debug packages policy?

Antoine Jacoutot-7
On Tue, Jan 21, 2020 at 11:57:23AM +0000, [hidden email] wrote:

> Antoine Jacoutot writes:
> > On Mon, Jan 20, 2020 at 11:31:11PM +0100, Christian Weisgerber wrote:
> > > What's the policy for adding debug packages to ports?
> > >
> > > Is the intend to add debug packages...
> > > * eventually to all ports
> > > or
> > > * only to ports where they seem particularly useful?
> >
> > I think the policy is up for debate really.
> > Nothing has been decided yet.
> > My humble opinion is that "particularly useful" is subjective...
>
> It would be more useful I think to make the ports and release build
> processes more approachable so that debugging symbols can be made
> available. If they need it, that is - I haven't had any real trouble
> beyond locating the correct documents to read and fumbling my way
> through.
>
> The reason being that including debugging symbols means you're,
> well, debugging. In the event that something bug-like is discovered
> debugging symbols will certainly make the stack traces sent to
> maintainers & developers more useful but a full OpenBSD build
> environment *right there* makes it easier to fix the bug where it
> was discovered and where that fix can be tested, resulting in not
> only a patch, but a *working* patch.
>
> When making things easier for people, I prefer to make it easier
> for people to make my work easier, not make it easier for them to
> just give me more work.
>
> Perhaps the enormous packages could have debug-symbol-filled variants
> but these days even that argument holds little water. I don't have
> the numbers to hand but the things which have traditionally had the
> worst build times - kernels, gcc, java, X, even firefox until they
> brought rust in to repair that oversight - now have build times
> measured in hours or minutes rather than weeks.
>
> tl;dr: grep -ri strip /usr/share/mk and, yes, read. No ";dr" for you.
>
> </tuppence>

I don't quite understand your mail.
I am not sure you're talking about the same thing naddy@ was...

See this:
https://man.openbsd.org/bsd.port.mk.5#THE_DEBUG_PACKAGES_INFRASTRUCTURE

--
Antoine

Reply | Threaded
Open this post in threaded view
|

Re: Debug packages policy?

chohag
Antoine Jacoutot writes:
> On Tue, Jan 21, 2020 at 11:57:23AM +0000, [hidden email] wrote:
> >
> > </tuppence>
>
> I don't quite understand your mail.

This:

> > > > What's the policy for adding debug packages to ports?

but ...

> See this:
> https://man.openbsd.org/bsd.port.mk.5#THE_DEBUG_PACKAGES_INFRASTRUCTURE

... I had conflated debug packages with stripping (or rather, not)
binaries so I was off on a bit of a tangent.

If debug packages are needed the functionality exists to make them,
in even better form than I had supposed, and if debugging needs to
be done then having a complete build environment is worlds apart
more useful than a symbol table (I presume the debug packages have
a bit more than that but I haven't looked).

So to get to the original point, DEBUG_PACKAGES doesn't look like
something that's useful in the public version of /usr/ports. If
anybody needs it then they've already got a complete (& working &
tested) OpenBSD build environment in which to add it and do their
debugging. What use the extra load on servers and maintainers?

</fourpence>

Matthew

Reply | Threaded
Open this post in threaded view
|

Re: Debug packages policy?

Marc Espie-2
In reply to this post by chohag
On Tue, Jan 21, 2020 at 11:57:23AM +0000, [hidden email] wrote:

> Antoine Jacoutot writes:
> > On Mon, Jan 20, 2020 at 11:31:11PM +0100, Christian Weisgerber wrote:
> > > What's the policy for adding debug packages to ports?
> > >
> > > Is the intend to add debug packages...
> > > * eventually to all ports
> > > or
> > > * only to ports where they seem particularly useful?
> >
> > I think the policy is up for debate really.
> > Nothing has been decided yet.
> > My humble opinion is that "particularly useful" is subjective...
>
> It would be more useful I think to make the ports and release build
> processes more approachable so that debugging symbols can be made
> available. If they need it, that is - I haven't had any real trouble
> beyond locating the correct documents to read and fumbling my way
> through.
>
> The reason being that including debugging symbols means you're,
> well, debugging. In the event that something bug-like is discovered
> debugging symbols will certainly make the stack traces sent to
> maintainers & developers more useful but a full OpenBSD build
> environment *right there* makes it easier to fix the bug where it
> was discovered and where that fix can be tested, resulting in not
> only a patch, but a *working* patch.
>
> When making things easier for people, I prefer to make it easier
> for people to make my work easier, not make it easier for them to
> just give me more work.
>
> Perhaps the enormous packages could have debug-symbol-filled variants
> but these days even that argument holds little water. I don't have
> the numbers to hand but the things which have traditionally had the
> worst build times - kernels, gcc, java, X, even firefox until they
> brought rust in to repair that oversight - now have build times
> measured in hours or minutes rather than weeks.

You're not making any sense, and I don't think you get what we are
talking about.

My opinion on DEBUG_PACKAGES is that eventually, most packages that could
use some debug will have DEBUG_PACKAGES.

In most cases, setting DEBUG_PACKAGES is enough.

Doing this package-by-package gives a chance for the mirrors to "grow"
the space needed little by little.

The exception will be:
- ports where it's extra complicated to get debug (obviously not too many)
- trivial leaf ports that can get rebuilt in <5mn.

Reply | Threaded
Open this post in threaded view
|

Re: Debug packages policy?

Stuart Henderson
In reply to this post by Christian Weisgerber
On 2020/01/20 23:31, Christian Weisgerber wrote:

> What's the policy for adding debug packages to ports?
>
> Is the intend to add debug packages...
> * eventually to all ports
> or
> * only to ports where they seem particularly useful?
>
> --
> Christian "naddy" Weisgerber                          [hidden email]
>

The policy I have been using myself is

- common libraries

- ports where I suspect there are likely to be crashes that
I think debug symbols would reasonably help

- ports that take a long time to build (but this is very handwave-y)

Reply | Threaded
Open this post in threaded view
|

Re: Debug packages policy?

Antoine Jacoutot-7
In reply to this post by chohag
On Tue, Jan 21, 2020 at 02:00:52PM +0000, [hidden email] wrote:

> Antoine Jacoutot writes:
> > On Tue, Jan 21, 2020 at 11:57:23AM +0000, [hidden email] wrote:
> > >
> > > </tuppence>
> >
> > I don't quite understand your mail.
>
> This:
>
> > > > > What's the policy for adding debug packages to ports?
>
> but ...
>
> > See this:
> > https://man.openbsd.org/bsd.port.mk.5#THE_DEBUG_PACKAGES_INFRASTRUCTURE
>
> ... I had conflated debug packages with stripping (or rather, not)
> binaries so I was off on a bit of a tangent.
>
> If debug packages are needed the functionality exists to make them,
> in even better form than I had supposed, and if debugging needs to
> be done then having a complete build environment is worlds apart
> more useful than a symbol table (I presume the debug packages have
> a bit more than that but I haven't looked).
>
> So to get to the original point, DEBUG_PACKAGES doesn't look like
> something that's useful in the public version of /usr/ports. If
> anybody needs it then they've already got a complete (& working &
> tested) OpenBSD build environment in which to add it and do their
> debugging. What use the extra load on servers and maintainers?

Sorry but that does not make sense.
The whole point is to have debug packages available for official packages.
Not be forced to rebuild anything.
And we already have many (more than 370 debug-* packages in the snapshots
directory).

For 99% of them it only means adding DEBUG_PACKAGES=${BUILD_PACKAGES} in the
port Makefile.
I run bulk 24/7 and I maintain 300 or 400 ports (I stopped counting years ago),
I think I am entitled to say they're no real extra load here... unless I am
misunderstanding what you mean.
I think you should read the DEBUG_PACKAGES framework to understand.

--
Antoine