Re: Automatic Debug Packages
On Wed, Aug 12 2009, Russ Allbery wrote:
> Paul Wise <pabs@debian.org> writes:
>
>> Not having anything to do with Ubuntu, I don't know anything about the
>> details, but they have had automatic debug packages and automated
>> crash report stuff for quite a while, a couple of years IIRC. The
>> specs for that are here:
>>
>> https://launchpad.net/ubuntu/+spec/apt-get-debug-symbols> https://launchpad.net/distros/ubuntu/+spec/automated-problem-reports
>
> Ah, thank you!
>
> https://wiki.ubuntu.com/AptElfDebugSymbols is the specification. It
> does use *.ddeb. There isn't any clear statement about how *.ddeb
> packages differ from *.deb packages. It looks like, by and large,
> they don't, except they may not need to contain the same set of
> things. The packages are not in debian/control or the things fed from
> it, but are in *.changes.
Thanks for the link.
They mention:
--8<---------------cut here---------------start------------->8---
# They (ddebs) can be arranged in a proper pool structure with a
Packages file etc., so that existing tools to mirror, download, and
ship debs can be reused.
# Users can actually install them if they want to.
...
An apt frontend will be provided to conveniently install debug symbols:
e. g. apt-get debug apache2 would install the -dbgsym ddebs for apache2
and all its dependencies. This will allow developers to actually install
the .ddebs
--8<---------------cut here---------------end--------------->8---
This is what I find interesting. So, not quite
aptitude/synhaptic, but analogous to apt-get source. This does answer
some of the questions I had about implementation.
> Ubuntu is creating one debug package per binary package, as I and a few
> other people have said we prefer. However, they're using the
> gnu_debuglink method, not the id method, so they don't have the one
> problem with that method previously identified in this thread when the
> same binary is copied into multiple packages.
Or the facility to keep debug symbols around for multiple
versions of shared libraries (with the same soname), which is an
advantage the build id method has.
> The proposal appears to only work for packages using debhelper, although
> the steps are laid out so presumably they could be done manually if need
> be.
Yes, though some sleight of hand might be needed do build a
package which is not in control (dpkg-deb --nocheck), or if the package
is in debian/control, debian/files would have to have the .deb line
removed, and dpkg-distaddfile used to register the ddeb file name).
> Ubuntu uses -dbgsym as the magic namespace. I don't know if it would be
> good for us to do the same or to use a different namespace to avoid
> problems for them in cases where we decide to build the package manually
> via debian/control and debian/rules.
I would still like to see coverage figures to figure out what
percentage of the archive will need this.
> It looks like the plan with *.ddeb is to treat them specially in the
> archive software and divert them into a different tree in the archive
> instead of using a separate archive area, which I think they're doing
> now from that page. It also looks like one of the justifications for
> the separate package is to hide them in the apt front-end so that
> users don't see all the additional packages. I'm personally skeptical
> this is a good idea, although I can see the merits of not returning
> them in apt-cache search.
I am not sure I see that. When I ask apt cache for packages that
currently have a debug package, I do not see the rpesence of
information about the debug package as garbage; it is nice to know that
the debg information exists.
> Ah, and it looks like the automated crash reporting offers to download the
> -dbgsym packages and install them.
Reading the spec, it seems to me that the primary motivation was
for users to provide crash dumps with bug reports, and not much screen
time is given to users debugging their own applications linked to
vendor libraries, or for the developer user in general. I think that
use case should be addressed as well.
> I don't see any sign in this of a share.
I am not sure I see much utility in a share, personally, since I
have not really had an installation where I spent any time in where the
mount would not have been prevented by perimeter defenses and security
policies.
manoj
--
"Help save the world!" --Larry Wall in README
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: