Re: dbgsym packages and backports
Hi,
* Niels Thykier <niels@thykier.net> [2016-01-14 08:36:52 CET]:
> Jens Reyer:
> > 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.
Well, that's an easy call. ;) Given that I'm uncertain how the
dbgsym should be handled here I'll pass that ball on to the regular 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.
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.
> > 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.
Which the backports FTP masters can't do. That's for the regular FTP
masters to decide/do.
> Once they had that, dbgsyms would be accepted automatically and go to
> the correct mirror.
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.
> 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.
> > 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.
Mistakes can happen and will. I'm not sure if a dak rm would do the
right thing here, I'll investigate. So far I don't know if the
debhelper is/was the only thing tainting the chroot for those two
backports that produced the -dbgsym packages, so it might affect more
than that.
> 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?
> > 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.
I guess that sounds like a sane approach - at least for now until we
find out more. It at least provides less pain to deal with in case
things are more clear in the longer run I'd say.
So long,
Rhonda [mostly without backports team hat on, but still influenced by it]
--
Fühlst du dich mutlos, fass endlich Mut, los |
Fühlst du dich hilflos, geh raus und hilf, los | Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los |
Reply to: