[Pkg-utopia-maintainers] dbus-broker Debian packaging

[David Herrmann]

Hey Daniele!

On Mon, Mar 5, 2018 at 12:20 AM, Daniele Nicolodi <daniele at grinta.net> wrote:
> Hi David,
>
> On 04/03/2018 05:08, David Herrmann wrote:
>> *) The dbus-broker project uses submodules to link some code
>> statically. The easiest way to build dbus-broker is using our .tar.xz
>> tarballs provided with each release [1]. These include *all* source
>> files, including the right submodule versions. If you want to build
>> from -git directly, though, I recommend the strategy used by the
>> arch-linux -git package [2]. They check out all required repositories
>> and then use git to check out the correct revisions. This is
>> definitely more flexible than the tarball based approach, but also
>> needs slightly more maintenance, as you need to stay up-to-date with
>> the submodules.
>
> Debian tooling handles the submodules fine, I just compared the released
> tarball for v11 with the one generated by the Debian tooling from the
> git repository and they are substantially identical.

Very nice! Sadly, other distro's are not on-par there, yet. Which is
why we provide the tarball..

> However, I noticed that not all the submodules have the same license as
> dbus-broker, I need to complete the debian/copyright file. Also, I
> noticed that Red Hat is listed as the copyright holder. Is that true for
> all contributions?

dbus-broker is licensed ASL-2.0, as well as all submodules. Some
submodules are additionally licensed under LGPL-2.1+.
Also all the copyright statements should be correct. I think there is
no other than Red Hat so far.

>> *) The dbus-broker binary itself is definitely intended to be useful
>> on its own. However, no such users are known, and so far we have *not*
>> stabilized its API, yet. Hence, I would not split it apart now, but
>> leave it for a future extension. That is, something like a
>> `dbus-broker-core` package, which just contains the broker, but not
>> the launcher.
>
> I think that having `dbus-broker` and `dbus-broker-launcher` packages
> would be more logical, but I don't see reasons why the split cannot
> happen when the need will emerge, or when the API will be stable.

I agree. I leave it up to you to decide. However, I think leaving it
as `dbus-broker` is the more friendly user-facing name for the
package. *Iff* the broker itself is ever split off, it will only be a
dependency of other packages, so `dbus-broker-core` (or similar) feels
more natural to me.
We use `dbus-broker` in ArchLinux and Fedora to contain the
launcher+broker. If only for consistency, I'd recommend the same for
Debian. But really, no strong feelings here and all up to you. There
are arguments either way.

>> *) We are reworking the Fedora package at the moment. I cannot say how
>> the ultimate solution will look like, but the plan right now is this:
>> dbus-daemon is split into multiple packages. One packages
>> (dbus-daemon-utils) provides all the utilities (dbus-send,
>> dbus-monitor, ...).
>
> I would call this `dbus-utils`, but.. bikeshedding.

Right! That sounds reasonable. I adjusted our WIP plans.

>> Another package (dbus-daemon) provides the daemon
>> binary and its related tools (dbus-daemon, dbus-launch, ...), as well
>> as a renamed service file `dbus-daemon.service`.
>> For dbus-broker we provide one package that ships the broker+launcher,
>> as well as the dbus-broker.service unit file.
>> Lastly, we intend to recreate the `dbus` package as a simple package
>> that both dbus-daemon and dbus-broker depend on, and it provides the
>> daemon-xml files (config and policy).
>
> If there is interest for dbus-broker in Debian and the dbus maintainers
> agree, I can work on patches to do the same for the Debian's dbus package.

I am in discussions with the Fedora dbus-daemon maintainer, and I hope
we can sketch out the plans for Fedora this week. I will keep you
updated with any possible changes.

>> Depending on what the default setup for your system should be, you
>> should run `systemctl enable dbus-{daemon,broker}.service`. They will
>> then create the dbus.service symlink. Fedora intends to use the
>> systemd-presets for this.
>
> That would need to be done differently on Debian, I guess.  I will need
> to do some reading about what the correct solution would be there.

I think debian has the 'alternatives' system, which might apply here.
But yeah, I am no big help as I haven't looked into that much.

>> I hope this information is of help to you!
>
> Thank you for the detailed reply, it surely helps.

You're welcome! Great to see Debian providing dbus-broker!

Thanks
David