On 2015-04-04 12:58, Esokrates wrote:
> On Saturday, April 04, 2015 10:54:09 AM Niels Thykier wrote:
>> [...]
>> - Trying to get the reproducible team to try it out to see if it
>> regresses anything (incl. reproducible builds)
>
> I guess the ddeb's are meant to be reproducible too?
>
Yes. The .ddebs are currently being built by the reproducibility team
on jenkins.debian.net and they are indeed reproducible themselves (after
we extended a patch the "reproducible" debhelper patch series to account
for them IRT mtimes).
>> - It *does* cause dpkg-genchanges to emit warnings about
>> uninitialized values (I think 3 per ddeb). Related to #781074
>> - DOES *NOT* PRODUCE DDEBS FOR PACKAGES COVERED BY AN EXISTING -dbg!
>
> Sounds like you plan to keep -dbg packages? Or just for migration? Ubuntu
> kept
> -dbg packages and tries to maintain -dbgsym along it (but they only cover
> packages that no -dbg package exists for, otherwise it will be an empty
> package, no idea if they situation is still like that there ...), however the
> situation was kind of messy, I often got file conflicts. Things were not
> consistent at all last time I needed debug packages for a lot of stuff there.
> Simply put: If you installed the debug package for every installed package,
> you get the hell of a mess, this was almost undoable. (That test maybe does
> not make a lot of sense, but it did show that things were not optimal.)
>
I have no particular interest in keeping existing manual -dbg packages.
However, there seemed to be little point in creating a .ddeb which is a
perfect clone of an existing -dbg with neither of them being co-installable.
Please also note that there are some existing manual debug packages that
we *cannot* migrate to ddeb currently (at least not as-is). E.g.
perl-debug provides debug symbols but also a "debugperl" binary etc.
So the prototype patch plays it safe and only generate .ddebs if the
debug symbols would otherwise have been discarded. This also means that
if the -dbg does not cover all binaries, debhelper will generate .ddebs
for the "uncovered" binaries (where applicable).
>> - DOES *NOT* ADD BREAKS/REPLACES FOR MIGRATING FROM -dbg TO .ddeb!
For reference, this limitation is due to time constraints - I intend to
have a solution for this problem (but it will probably have to be manual
- maybe an argument for dh_gencontrol).
>> [...]
>
> I know predictions are hard, but is there a plan to get things done for the
> next release (Stretch)?
>
At this point, there is no plan, sorry. However, we got a functional
prototype (for part of the problem) and some people poking a bit at it
from a "design view". I received conflicting remarks:
A) Use ".ddeb" (i.e. with an extra "d").
B) Use ".deb" (i.e. the regular extension) with a new "section".
Both have their own advantages and disadvantages. In particular:
A) means that almost every existing tool will handle the debug debs
like a regular deb (which it is) and will generally work perfectly
out of the box.
- There are a couple of exceptions, but we are limited to something
like lintian and dpkg-genchanges.
- There will be tools that might want to handle them differently.
Programs like dak and reprepro might want to (support) put(ting)
them in a different part of their repositories.
- This is *currently not working* since dpkg-genchanges errors out
on the auto-generated .deb files.
B) means that .ddebs can be special cased on filenames rather than on
section (like udebs). Furthermore, there might be a lot of things
that do not need to support .ddebs at all.
- Downside is that adding support is a manual extra step for many
tools, that (besides the filename) would otherwise be able to
handle .ddebs immediately.
- On the plus side: dpkg-genchanges in Jessie can support this
solution immediately with a minor warning.
>From my point of view, I am not strongly attached to one solution over
the other:
* I am slightly preferring A), but I am ready to implement either
solution in the tools, I maintain.
* The difference for debhelper is a single "d" and a section name.
* The change for lintian is larger, but B) is the "heavy" solution
and I already got a "mostly working" patch for that.
> Thanks for the very comprehensive status update and your awesome work!
>
>
You are welcome. :)
Thanks,
~Niels
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55242b97.5080...@thykier.net
