Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)

[Niels Thykier <niels@thykier.net>]

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