Emilio Pozuelo Monfort <poch...@gmail.com> 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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
