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

Re: Better infrastructure for dbgsyms

Stefan Fritsch:
> Hi,
> [...]


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.

> - 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 
> sources.list.
> Cheers,
> Stefan

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)


Reply to: