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

[Niels Thykier <niels@thykier.net>]

On 2015-04-09 09:25, Esokrates wrote:
> On Tuesday, April 07, 2015 10:11:18 PM Niels Thykier wrote:
>> [...]
> 
> So mostly that is more a decision making (political) problem, than a technical 
> one.

It is not entirely clear to me that we any have (major) political issues
IRT ddebs.

People generally seem to be positive (or "worst case" indifferent) to
the idea itself.  There also seem to be agreement about what goes into
the ddebs, where it is placed and they are "just another deb" (etc.).
  As mentioned, the only real concern seem to be whether or not it
should be a ".ddeb" or ".deb".  Though I doubt it is going to be
problematic - if this was truly something people felt for strongly, I am
certain they would have expressed their opinion by now.

> Stretch is a two year time frame though, which makes me kinda sad. Thanks 
> for you effort though, keep up the amazing work! If I understand correctly, if 
> it would have been something for stretch, either A or B would have been 
> decided already and partly implemented, right?

I believe we can implement this for Stretch if we wanted to.  Unlike
multi-arch, build-profiles (etc.), ddebs are already supported by our
(14-days-from-now-new) stable release.  Namely,

 * All the groundwork requirements (pkg:arch dependencies etc.) are
   already covered by previous efforts.
   - I.e. everything that would require a full-cycle for support are
     already done in time for Jessi

 * What we are missing is mostly support from our infrastructure and
   repository tools.  As far as I am informed, the main blockers here
   are:
   - With .ddebs => dak, debhelper
   - With .debs  => dak, debhelper, dpkg-dev
   None of which

 * Known list of tools where support is (very) "nice-to-have", but not a
   strict blocker.
   - lintian - though people on d-mentors might disagree. ;)
   - reprepro and similar
   - others?

 * List of (assumed) "support is completely optional or even
   unnecessary"
   - buildd/sbuild/wanna-build - it should just be a regular build for
     these with debhelper doing the heavy lifting.
   - britney - the ddebs build by debhelper are just as (co-)
     installable as the .deb they are based on.

> I am looking forward to the day, when both reproducible builds and automatic 
> debug package exist, that will be an awesome future! 
> Thanks very much for outlining this, Niels!
> 
> 

I certainly agree!  I cannot take credit for the reproducible builds
though. :)

[Different mail, same sender]:
> 
> Or maybe another question: Will it be ready for sid, soon? Sorry, I am really 
> excited about this.

Good question really.  I can certainly upload a version of debhelper to
unstable that has /opt-in/ support for ddebs when Stretch opens.
However, to have them on the mirror largely depends on when dak gets
support for ddebs.  Unfortunately, I do not have any ETA on that.

Thanks,
~Niels