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
