[systemd-devel] sd-bus change that broke sdbus-c++

[Lennart Poettering]

On Mi, 10.06.20 18:24, Stanislav Angelovič (angelovic.s at gmail.com) wrote:

> Hi folks,
>
> sdbus-c++, a C++ library on top of sd-bus, is based on plain sd-bus
> messages to implement the concept of Variant type. Under plain message here
> I mean one created via `sd_bus_message_new` with the type being
> _SD_BUS_MESSAGE_TYPE_INVALID. We use such a message as a generic container
> of serialized D-Bus data, from which we read and to which we write. More of
> this, including an example, is explained in the mailing list thread spawned
> a year ago:
> https://lists.freedesktop.org/archives/systemd-devel/2019-May/042748.html.
>
> That all of sudden stopped working with systemd 245.6. The reason is highly
> likely this commit in systemd:
> https://github.com/systemd/systemd/commit/a2dd991d0fde59dc0574bd4d0c1438f01dc0b8ff.
> This commit changed `sd_bus_message_new` to be more strict and immediately
> reject creating messages of type _SD_BUS_MESSAGE_TYPE_INVALID, whereas
> before that case was allowed, as were also allowed a few serialization
> operations upon such a message (the rest like enqueuing checked the type
> and failed, naturally). That original behavior was a perfect match for our
> need for plain sd-bus messages. I understand that this was based on
> internal implementation of sd-bus, since as I checked the documentation
> now, it instructs clients to use one of the method call, method return,
> method error and signal types.
>
> What would you suggest as a solution in this situation? Would it be
> possible to get back to the original behavior? Or would you suggest
> creating a new API method for creating plain messages? Any is fine for
> sdbus-c++, but the latter is a little more difficult because we cannot
> conditionally decide upon the behavior in our code based on the systemd
> version, as 245 exhibits various behaviors depending on the minor version...

Please file a bug on github.

Lennart

--
Lennart Poettering, Berlin