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

Re: dbgsym packages and backports

Rhonda D'Vine:
>       Hi,
> * Niels Thykier <niels@thykier.net> [2016-01-14 08:36:52 CET]:
>> [...]
>>> Generally:
>>> Debhelper in jessie-backports (9.20150101) doesn't support this. Is
>>> anybody planning to backport debhelper for jessie-backports?
>> Recent versions of debhelper has removed support for compat 1+2 (and
>> quite soon, compat 3).  I doubt this is something you want to/in
>> backport(s).
>>  On the other hand, backporting the particular changes needed to build
>> dbgsyms should be less problematic.
>  I rather would not see that feature added to backports specificly if
> the rest of the rest of the archive doesn't know how to handle it.
> Though: We have -dbg packages in stable and AIUI those automaticly
> created -dbgsym package isn't too much different from those, so it
> shouldn't be a big trouble.

Hmm, I got sad news: debhelper needs a patch or two to dpkg-dev for this
to backported.  Which is mostly sad because...

>> [...]
>  Currently we have six -dbgsym packages in backports which seem to have
> slipped in by accident, because they are only built for amd64 but no
> other architecture.
>  With that I like to emphasize: *Do* build your backported packages in a
> stable environment with *no* stuff appart from backports in.  There is
> no debhelper package in backports that would create -dbgsym package, so
> the chroot that did produce those binaries is tainted.  Fix that.  Now.

At least dpkg-dev would also have to be tainted as well.  I suspect you
are looking at packages built in a sid or testing chroot. :-/

Package: debhelper
Depends:  ..., dpkg-dev (>= 1.18.2~), ...

That version of dpkg-dev is required to support dbgsym packages.

>> The problem with testing is that we need to patch Britney to /migrate/
>> the dbgsyms to testing.  Without that, the testing debug suite will
>> simply just be empty (or out of date).
>>   This affects stable because the empty/out-dated "testing-debug" would
>> eventually be copied into/replace "stable-debug".
>  So before that happens any further discussion about dbgsym in backports
> doesn't make any sense to me.


>> [...]
>> 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).
>>   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.
>  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. :)

> [...]
>  So long,
> Rhonda [mostly without backports team hat on, but still influenced by it]


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: