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

Re: dbgsym packages and backports

Jens Reyer:
> Hi,
> how should we (backports) handle packages that build the new dbgsym
> packages? (CCing Niels who sent the announce mail[1].)


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
 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.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: