Re: Better infrastructure for dbgsyms
- Date: Fri, 11 Aug 2017 16:15:39 +0200
- From: Bastien ROUCARIES <roucaries.bastien@xxxxxxxxx>
- Subject: Re: Better infrastructure for dbgsyms
On Thu, Aug 10, 2017 at 9:56 PM, Niels Thykier <niels@xxxxxxxxxxx> wrote:
> Stefan Fritsch:
> Thanks for improving dbgsym integration. :)
>> 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).
> 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
> * To make dbgsym packages trivially policy compliant (without
> duplicating the copyright file), I used usr/share/doc symlinks.
Do you link the doc dir or only the copyright file ? if it is a dir it
will be a mess (see dpkg-maintscript-helper symlinktodir)
BTW do we have created a depends ddeb-support (=version) ? If no do we
have a plan of how to change format ?
The = depends ease transition also. So I want to have the point of
view of release team about this
>> - 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.
> By introducing a dependency from "debian" to "debian-debug", you would
> basically introduce a unsatisfiable dependency (for users, whom have not
> opted in to the "debian-debug" archive).
> Largely, it is the technically similar to a package in main depending on
> a package in non-free (except for the legal/ethical implications).
>> - 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).
>> - 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
> 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)