Re: Status of deb(5) format support in Debian
On Wed, Jul 31, 2013 at 06:56:40PM +0200, Stefano Zacchiroli wrote:
> 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).
Worse, I am guilty of also having implemented the same functionality in
the same language again. The interfaces provided by python-debian are
insufficient[1] for fixed-memory package processing. Is there any chance
of getting this fixed in python-debian? It would likely require adding
or changing a number of interfaces.
> 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.
For the compression support (data.tar, data.tar.xz), you can "borrow"
the implementation from dedup.d.n. The license should be compatible and
relicensing should not be an issue if needed. Indeed, this could be a
move of the code if I could start using python-debian.
> 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.
While having the C library exposed to other languages might appear like
a good idea, it misses an important point. Other languages may prefer an
asynchronous way of interfacing with data. Mapping this into C basically
requires that all exported functions are fully side-effect free, which
in most cases enforces a state-driven or continuation passing style
interface. At the very minimum, it requires that io operations are
replacable. This is not what libdpkg* implements. Instead it adheres to
KISS as far as it can.
Helmut
[1] A major issue is that ArFile uses seek. I suggest moving to
python-arpy (#704594), because it fixes these issues and this will
avoid duplication.
Reply to: