Debug package

[Fabian Fagerholm]

(Please don't cc me on list posts, I'm subscribed ;)

On Tue, 2006-11-14 at 08:52 -0500, Roberto C. Sanchez wrote:
> Out of curiousity, would this be better than having a -dbg for each
> corresponding lib package?  I understand that from a convenience
> perspective, it is nice to not have to worry about whether the user has
> the right debugging package installed.  My promary concern, however is
> that the size of a single package with all the symbols might be a bit
> large.  Though, I have not built the package to check.

You're right that the package takes up some space compared to the other
packages. It's 536k and by far the largest of the binary packages we
build. (The -dev package is 260k, second largest after -dbg.)

On the other hand, the package is meant to be installed while debugging,
and it needn't be installed otherwise. So the user can just remove it
after having obtained the debug info with gdb. As for taking up archive
space, well, it's a tiny bit smaller than adding separate packages.

Finally, its maintenance is ridiculously easy. You basically have to do
nothing, dh_strip does all the work now and there is no NEW overhead.
Separate packages would involve some more elaboration in debian/rules
and it's easy to forget to add and maintain matching -dbg packages.

> We may want to check with the FTP masters and see if they can fast track
> this.  I appreciate the need to fix as many bugs as possible and I think
> that in the last six weeks we have worked the bug list for cyrus-sasl2
> down to be the shortest it has been in an extremely long time.  However,
> I am concerned that the constant churn may put the RMs off from wanting
> to include it in Etch.  We may need to form a very compelling argument
> (e.g., the current Sarge/Etch version will be nearly impossible to
> support from a security perspective, etc) in order to make it in.

I think we're actually quite stable already. Integration issues have
revealed some bugs in the initscript and the build-time settings, but
the fixes have been very small and more or less obvious. Then, there's
been some bug activity, but that'll settle down as we become convinced
that we've really fixed those issues and not accidentally forgotten
something.

In fact, I think shipping the -dbg package with etch is a *really* good
idea, because otherwise it'll be very hard to say anything useful about
segfault reports. And that'll last for a whole release.

I do think we need to make a compelling argument, but I think we've done
some good groundwork, and we're even able to look ahead a little bit and
prepare for issues which we know are going to surface. This can't be bad
from the RM's perspective. :)

My current thinking is that we go through NEW with -dbg starting in two
days or so, then we look at our status and try iron out any remaining
issues, aiming for stability. This shouldn't be more than a week, two
tops. After that, we ask the RMs (Steve Langasek has agreed to handle
our case) to take a look and come up with a list of issues that they'd
like us to fix before they're comfortable letting this into etch. Of
course, we adapt to circumstances, but that's how I see things today.

-- 
Fabian Fagerholm <fabbe at paniq.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/pkg-cyrus-sasl2-debian-devel/attachments/20061114/4d759bf6/attachment.pgp