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

Re: Better infrastructure for dbgsyms



On Thu, Aug 10, 2017 at 9:56 PM, Niels Thykier <niels@thykier.net> wrote:
> Stefan Fritsch:
>> Hi,
>>
>> [...]
>>
>
> 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
>    packages
>
>  * 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
>> 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)
>
> Thanks,
> ~Niels
>


Reply to: