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! -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3487072.50TJyGfKk4@ubuntu
