[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Better infrastructure for dbgsyms (was: Automatic way to install dbgsym packages for a process?)


On Wed, 9 Aug 2017, David Kalnischkies wrote:
> I haven't seen the perl script (and I don't speak perl, so even if
> I had), but from the description of the functionality it doesn't sound
> too hard and like a natural fit. Personally I would just prefer if
> someone writes it who knows how it should work and would use it – not me
> who doesn't even have the debug archive in its sources (as libc6-dbg is
> not a -dbgsym yet) nor deals with crash.dumps all too often…
> Long story short: I am happy to help via IRC/deity@ & Julian is at
> DebConf in case someone wants to talk about apt in person.

I agree that integration in apt would be a good idea. But until then, 
having the script packaged makes sense. I have filed a wishlist bug 
agianst debian-goodies:


BTW, in some discussions some other questions were raised:

- Is it really a good idea that foo-dbgsym depends on "foo (== 
foo-version)"? Wouldn't a Conflict or breaks on "foo (!= foo-version)" 
make more sense respective package? Consider that you want to analyze the 
core dump on a different system and foo may pull in quite a lot of 
dependencies, start servers, etc.

- Is it allowed for packages that are not in the debug section to depend 
on packages in the debug section. For example, to make a meta package that 
depends on a set of useful dbgsym packages? But the need for this would 
probably go away with better apt integration.

- Would an option to put all symbols from a source package into a single 
dbgsym package make sense? This would allow to get rid of all those dbgsym 
packages with only a single small file in them.

- Should we put the URL of the debug sym sources.list entry into the 
release file of the non-debug sym section? That way, apt could determine 
the location of the dbgsym packages by itself without having to edit 


Reply to: