Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)
On Tuesday, April 07, 2015 10:11:18 PM Niels Thykier wrote:
> On 2015-04-07 21:10, Niels Thykier wrote:
> > On 2015-04-04 12:58, Esokrates wrote:
> >> On Saturday, April 04, 2015 10:54:09 AM Niels Thykier wrote:
> >> [...]
> >> 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".
> I managed to confuse myself here and swapped A and B in the above. What
> I meant to write was:
> A) Use ".deb" (i.e. the regular extension) with a new "section".
> B) Use ".ddeb" (i.e. with an extra "d").
> The rest should now make sense - apologies for the confusion:
> > 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.
> > [...]
So mostly that is more a decision making (political) problem, than a technical
one. 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 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!