Re: Status of deb(5) format support in Debian
Hi!
On Wed, 2013-07-31 at 22:16:02 +0200, David Kalnischkies wrote:
> On Wed, Jul 31, 2013 at 6:56 PM, Stefano Zacchiroli <zack@debian.org> wrote:
> > Can you expand on the planned remedy and in how "soon" it might arrive?
>
> That I would be interested in as well.
> I know that everyone dreams about a stable API for a library, but I believe
> that even an unstable library at this point is way better than the status
> quo of having other layers like libapt (which is a proof that even if being
> unstable is a pain, the alternative would be worse – and that's a freaking
> C++ "library" …) providing makeshift replacements.
> There are e.g. a bunch of dpkg-style version-comparison implementations in
> Debian which should really just be a single one under the control of dpkg and
> that might be "just" ~5 because libapt includes one, so it could be misused
> by others (anyone remember the kernel depending on libapt-pkg-perl?).
Well that unstable (static) library is already there, it's in libdpkg-dev,
I added that package as a compromise, precisely because I considered that
better than nothing. And although I've been cleaning it up, the library's
main purpose has previously been just a dumping ground to share code for
the various dpkg programs, and that showed in the interfaces.
Providing a shared library out of that, though, while there's things
known to not be generally suitable outside of dpkg (like the non-freeing
allocation stuff on version parsing, for example), will imply pain for
everyone, will require either frequent SONAME bumps with the required
trips through NEW, immediate coordination with revdeps and RM transition
allocations, etc, or will make modifying it while it's known to not be
generally ready a drag. I'm sorry but I don't believe in shared libraries
bumping SONAME every other month, ideally they should almost never bump
them by way of symbol versioning.
I guess I could change the library description to be less scary, and
mark current and incrementally some of the specific functions (like the
version comparison) as more stable than others. Also if other software
starts using libdpkg.a (assuming its current unstability), it might be
a stronger motivator to clean it up for general use and an aid to see
what interfaces might need more work. For example when Clint switched
deets to use libdpkg that also helped see external usage patterns.
When it comes to .deb format support, libdpkg only contains the skeleton
(ar and tar support), the bulk of the logic is in dpkg-deb itself. I got
code while Debian was frozen to refactor and cleanup some of that so
that it can be moved to libdpkg. Will try to push it soon, as I want
to tackle the deb signature stuff Niels poked at some time ago.
The other side of the support I've been pondering about is extending
dpkg-deb so that .deb files can be modified in conformant ways, stuff
like inserting _-style members, or appending extra ones at the end,
which would cover the needs of several other tools.
> P.S.: Could the table be enhanced with a description for the table headers?
Sure, I thought they would be clear once one has read deb(5), but I
can expand them a bit, will do that tomorrow.
> I have no idea what an "ar slash" might be,
That's support for member names with a trailing '/', like the ones
GNU ar(1) produces.
> and not really what LFS means as the format has no support for >10
> character filesizes as far as I know.
See my reply to Neil, in apt's case the problem in the ar support
comes from AFAICS incorrect data types in ARArchive::LoadHeaders() for
offsets and sizes and downcasts.
Thanks,
Guillem
Reply to: