Jens Reyer: > Hi, > > how should we (backports) handle packages that build the new dbgsym > packages? (CCing Niels who sent the announce mail[1].) > Hi, Speaking with my debhelper/dbgsym implementor hat on. I will leave *all* decisions about backports to the backports FTP masters. > > 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. > Even with a newer debhelper I guess there are infrastructure changes > needed. Are there any plans for whatever is needed to support them? I > saw only posts about testing and stable(=stretch) requiring changes in > britney. > Both stable and stable-backports could trivially enable the required features. Basically, they need what is called a "debug-suite" in dak. Once they had that, dbgsyms would be accepted automatically and go to the correct mirror. * Whether we want that in backports is a different matter. 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". > What would happen without infrastructure adapted, but debhelper > backported? Would dbgsym packages just be ignored, or would this cause > errors? AFAIK debugsyms are currently only available for unstable and > experimental[2], so for jessie-backports with a backported debhelper the > same might happen as for stretch currently (whatever this is). > * Without a debug suite, the dbgsym packages will end up in backports-NEW on the upload AFAICT. - Should make them trivial to spot and REJECT. > > Specifically, current backporting practices: > > I am working on wine 1.8-2 (not yet in stretch) for jessie-backports. > This package has removed the -dbg package from debian/control and now > has in debian/rules: > > override_dh_strip: > dh_strip -Xwine-pthread -Xwine-kthread > --ddeb-migration='libwine$(VERSION)-dbg (<< 1.8-2~)' > > Previously it had: > dh_strip -Xwine-pthread -Xwine-kthread > --dbg-package=libwine$(VERSION)-dbg > > Reverting this change to bring back the -dbg package wouldn't work for > later updates from jessie-backports to stretch. (Unless we update the > ddeb-migration-version, which adds a versioned Replaces/Breaks, with > every upload to unstable). > 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. This requirement is harder to explain and check, which is why I (until now) refrained from talking about it. > I doubt that we want to ship unstripped binaries. > > So I think I'll just remove the override_dh_strip completly. Thus the > binaries will be stripped, but the debug symbols will be discarded. > > The -dbg package has a versioned depends, so it will be uninstalled on > update. I guess there is no need to add a Replaces/Breaks in libwine. > > Is this plan ok as long as no newer debhelper is available? > > > Greets and thanks everyone! > jre > > [...] Punting this to backports FTP master. Thanks, ~Niels
Attachment:
signature.asc
Description: OpenPGP digital signature