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. > Ok. >> [...] >> 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] > Thanks, ~Niels
Attachment:
signature.asc
Description: OpenPGP digital signature