On Wed, Jul 31, 2013 at 06:24:32PM +0200, Guillem Jover wrote: > Due to bug 718295, and in preparation to add non-gzip compression > support for control.tar, I've tried to get an accurate view of the > current deb(5) format support in software present in Debian. The > resulting table looks pretty bad: > > <https://wiki.debian.org/Teams/Dpkg/DebSupport> So, about the following passage on that page: > The current support seems quite bleak, and part of the blame goes to > dpkg for not providing better interfaces for others to use, hopefully > that will be remedied soon. Can you expand on the planned remedy and in how "soon" it might arrive? I'm myself guilty of having implemented, back in 2007, python-debian's support to manipulate .deb files: the debian.debfile module. It is yet another Python implementation of deb(5), because back in the days there was no libdpkg* libraries I could wrap around (IIRC). These days debian.debfile is lagging in compression formats support, as your table properly shows. (BTW, thanks for the bug reports!) That said, I'm not particularly keen of racing in features with dpkg/deb(5). I'd rather throw away the alternative Python implementation all together, and provide a Python wrapper around libdpkg*. But libdpkg-dev is still a static only library and comes with scary warnings about its API stability. Given the number of tools/libraries in need of fixing, this might be the good moment to rather ask them to migrate to some libdpkg* API instead. Thanks in advance for your advice, Cheers. -- Stefano Zacchiroli . . . . . . . zack@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Attachment:
signature.asc
Description: Digital signature