Hi, 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: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871620 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 sources.list. Cheers, Stefan
