Re: dbgsym packages and backports
On 01/14/2016 06:52 PM, Niels Thykier wrote:
> Rhonda D'Vine:
>>> [...]
>>> A little known "secret": The relation given to "--ddeb-migration" is
>>> /not/ required to be versioned (if you do not mind a "I"-tag from lintian).
With a lintian-override in every dbgsym package, and a comment to
explain when the migration is over, this might be a clean solution.
But I don't really like it - too much change in the other suites needed,
just to revert the move from dbg to dbgsym in backports.
>>> Secondly, the Breaks/Replaces are only "required" as long as one of
>>> the ELF build-ids of your current matches the one from the "-dbg"
>>> package. If all your ELF binaries contain "__DATE__" and "__TIME__" in
>>> them (or is otherwise built completely non-deterministic) you are
>>> probably safe.
Indeed I can install (from a local test build) e.g. libwine-dbg
(1.8-2~bpo8+1) and libwine-dbgsym (1.8-2) at the same time without file
conflicts...
>> But we are aiming at reproducible builds in general - might that cause
>> more troubles in that area?
>>
>
> Not if people use --ddeb-migration or pay attention to the Build-Ids of
> the debug symbols before omitting/remoivng said option. Though, I
> omitted that option originally exactly because I could be bothered to
> explains the "ifs and whens" of using the option. :)
... but verifying this for every upload to backports doesn't sound
promising imo. Neither does making the code build unreproducible on
purpose ;)
So I'll play safe/lazy/clean and stick to my plan to drop the debug
symbols completely for now.
Thanks a lot everyone for all of your answers, including the (non-)outlook!
jre
Reply to: