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

[Stanislav Angelovič]

 Done: https://github.com/systemd/systemd/issues/16193

On Tue, Jun 16, 2020 at 10:50 AM Lennart Poettering <lennart at poettering.net>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20200616/2bbe2679/attachment.htm>