Re: Automatic Debug Packages
Emilio Pozuelo Monfort <firstname.lastname@example.org> writes:
> Russ Allbery wrote:
>>> Except that in that case, the old library will be NBS and thus I see
>>> no point why you would want to keep it installed. The only reason
>>> would be if it was meant to stay around, but in that case I'm sure the
>>> source package names would be different.
>> Because you're trying to debug a binary on your system that's linked
>> against it.
> Then you should work on making your package build with the new library,
> since it will be FTBFS anyway :)
I was not under the impression that this system was intended only for the
use of Debian Developers.
> I don't consider this a real issue.
I do. I think it's a fairly significant one.
> There will still be a repository with all the .ddebs. But also we will
> have a share that will ship all the debugging symbols in a build id file
> hierarchy structure (so something like .build-id/xx/xxxxxxx.debug). You
> can mount it in your system and use it as if you had installed every
> -ddeb available in the archive. Furthermore, if disk space permits it,
> we will provide symbols for more than one version (i.e. not only the
> current package in the archive, but maybe the last three or whatever we
> can do), since build ids permit it.
> With this in place, we can integrate reporting tools (bug-buddy,
> drkonqi, apport) to use that service to magically provide meaningful bug
> reports with complete backtraces.
Hm, that's interesting, but I suspect that few enough of our users will be
able to use such a thing that we shouldn't let that influence any other
design choices. Most shares are not going to be able to be mounted
through firewalls, for example, so that form of the debug symbols won't be
available to quite a few users.
Or maybe by "share" you meant something that was more like a file download
service over HTTP than, say, NFS?
> If you use this, you won't need to get a backtrace, realize you're
> missing some symbols, install some more debug packages, rinse,
> repeat... :)
I thought you were planning on automating *this*, which I think is more
useful than providing a share. It seems like it would be fairly
straightforward in conjunction with the Contents database and the ldd
output on the binary that crashed.
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>