Re: Better infrastructure for dbgsyms
Thanks for your response, Niels,
On Thu, 10 Aug 2017, Niels Thykier wrote:
> > 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.
> >
>
> could be debugging coredumps from multiple versions on the same
> machine. As a debugger, you are basically interested in the
> /usr/lib/debug files themselves and not the dbgsym.deb.
> The .deb packages happen to be the only transport mechanism that
> Debian provides, but we should consider that they limit people to
> basically debugging on the same distribution as they are running (at
> least if you want to dbg files for libc and other low level libraries).
Yes, I agree that being able to only download and unpack the packages into
some directory should be available as an alternative. This would make
root-access un-neccessary.
In gdb, one can use 'set debug-file-directory' to a search patch with
several directories.
> Anyway, The relation was added for two reasons:
>
> * It was a "requirement" imposed to me when I wrote it from several
> others. I presume that it was historical to match that of -dbg
> packages
>
> * To make dbgsym packages trivially policy compliant (without
> duplicating the copyright file), I used usr/share/doc symlinks.
true, I hadn't thought about the copyright file.
>
> > - Is it allowed for packages that are not in the debug section to depend
> > on packages in the debug section. [...]
> >
>
> Not in Debian. The "main" component of the "debian" archive is
> self-contained; the "debian-debug" archive is an add-on on top of this.
> [...]
> Largely, it is the technically similar to a package in main depending on
> a package in non-free (except for the legal/ethical implications).
ok
> > - 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.
> >
>
> Technically, it should rather trivial if we ignore some corner cases.
> Notably, the dbgsym would no longer be (bit-for-bit) reproducible under
> "noX" profiles (that exclude packages).
>
> We might also have to replace the usr/share/doc symlink in favour of a
> real copyright file (or assume that dbgsym packages cannot contain
> copyrightable information / is not subject to license terms or define
> that they inherit their license information from $SOMEWHERE).
ok. That's probably not worth the effort, then.
> > - 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.
> I think that is an interesting idea and would go nicely hand in hand
> with the request for other mirror metadata in #761348 (like what is the
> base suite for "add-on suites" like experimental)
thanks for the pointer. I have sent a comment to that bug report.
Cheers,
Stefan
Reply to: