Bug#913683: apt: Please add support for package file lists API via libdpkg-dev
On Thu, 2018-11-15 at 13:59:15 +0100, Julian Andres Klode wrote:
> On Wed, Nov 14, 2018 at 02:46:33AM +0100, Guillem Jover wrote:
> > Source: apt
> > Source-Version: 1.8.0~alpha2
> > Severity: wishlist
> > User: debian-d...@lists.debian.org
> > Usertags: dpkg-db-access-interface
> > The dpkg database will be changing formats in the near future, and one
> > of the blockers is all the code accessing it directly w/o going via a
> > supported interface. These include packages already using libapt, and
> > others using python-apt. So adding an interface in libapt would make
> > it possible for python-apt to do the same, and all their users to use
> > that properly.
> >
> > A supported interface can be libdpkg-dev, which recently got support
> > for the file database, moved from the core dpkg code. Even though the
> > library is a static one, it should be built as PIC to support PIE
> > nowadays, so that should make it linkable for libapt. And even though
> > using a static library with a volatile API is not desirable, it's
> > probably better than any of the alternatives.
>
> So, I had a look at the API, and it does not seem usable at the
> moment. We need an API that we can hook into our error system:
>
> (1) A way to get the result of a function call, and an error message, if any;
> for example, by making functions return booleans, and ohshit{,e} _somehow_
> calling _error->Error by us providing a custom hook.
I think this is currently somewhat doable. The entire dpkg codebase is
really based on the notion of just calling ohshit*, and even though
I've been switching some of the code to use the struct dpkg_error
functions, changing the rest might take some time.
But you can control how ohshit* react by installing new error context
handlers, in your case, given that you'd want to continue execution
elsewhere, by installing a setjmp handler with push_error_context_jump(),
which will allow you to install your own custom error printer too.
> (2) A way for warnings to be converted to _error->Warning()
But, this is currently not possible. I'll be adding a hooking
mechanism for it.
> libdpkg as is basically just crashes the application, which is not
> a correct thing to do for a library.
See above, that should be currently avoidable. I'm more worried about
the thread-safety expectations from libapt, if any. Currently libdpkg
is not thread-safe at all. :/
Thanks,
Guillem
Bug#913683: apt: Please add support for package file lists API via libdpkg-dev
On Wed, Nov 14, 2018 at 02:46:33AM +0100, Guillem Jover wrote:
> Source: apt
> Source-Version: 1.8.0~alpha2
> Severity: wishlist
> User: debian-d...@lists.debian.org
> Usertags: dpkg-db-access-interface
>
> Hi!
>
> The dpkg database will be changing formats in the near future, and one
> of the blockers is all the code accessing it directly w/o going via a
> supported interface. These include packages already using libapt, and
> others using python-apt. So adding an interface in libapt would make
> it possible for python-apt to do the same, and all their users to use
> that properly.
>
> A supported interface can be libdpkg-dev, which recently got support
> for the file database, moved from the core dpkg code. Even though the
> library is a static one, it should be built as PIC to support PIE
> nowadays, so that should make it linkable for libapt. And even though
> using a static library with a volatile API is not desirable, it's
> probably better than any of the alternatives.
So, I had a look at the API, and it does not seem usable at the
moment. We need an API that we can hook into our error system:
(1) A way to get the result of a function call, and an error message, if any;
for example, by making functions return booleans, and ohshit{,e} _somehow_
calling _error->Error by us providing a custom hook.
(2) A way for warnings to be converted to _error->Warning()
libdpkg as is basically just crashes the application, which is not
a correct thing to do for a library.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Bug#913683: apt: Please add support for package file lists API via libdpkg-dev
Source: apt Source-Version: 1.8.0~alpha2 Severity: wishlist User: debian-d...@lists.debian.org Usertags: dpkg-db-access-interface Hi! The dpkg database will be changing formats in the near future, and one of the blockers is all the code accessing it directly w/o going via a supported interface. These include packages already using libapt, and others using python-apt. So adding an interface in libapt would make it possible for python-apt to do the same, and all their users to use that properly. A supported interface can be libdpkg-dev, which recently got support for the file database, moved from the core dpkg code. Even though the library is a static one, it should be built as PIC to support PIE nowadays, so that should make it linkable for libapt. And even though using a static library with a volatile API is not desirable, it's probably better than any of the alternatives. Of course, I'm happy to improve the libdpkg API to help with needs coming from apt, just let me know. Thanks, Guillem
