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

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

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


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


Reply to: