kumquat-buildroot/package/dbus-broker/dbus-broker.hash

18 lines
1.7 KiB
Plaintext
Raw Normal View History

package/dbus-broker: new package dbus-broker is an alternate implementation of a dbus daemon. It can be used as a drop-in replacement for the system bus daemon, as well as the session bus daemon. dbus-broker is (basically, and as far as we're concerned in Buildroot) split in two components: - the actual message bus daemon, that relays messages across clients - a launcher, which is responsible for setting various aspects of the bus, like setting the policy et al. and opening the socket(s) the message bus daemon will have to listen on... The launcher can only be used in a systemd setup (it makes heavy use of systemd facilities), while the message bus is generic. However, the message bus daemon is useless without a launcher. There does not exist a non-systemd launcher, which makes dbus-broker actually a systemd-only package; this can be revisited when/if a non-systemd launcher appears. Note, however, that libdbus is not provided by dbus-broker. People who want to use dbus-broker as the bus daemon, and need libdbus, will have to enable both. If only original dbus is enabled, things stay as they are now. This is for the moment still the default, though we should change that once dbus-broker has proven to work. If only dbus-broker is enabled, it installs the necessary socket activation units and dbus configuration files. The daemon is not launched at boot time; instead it is socket-activated when a client connects to the bus the first time. If both original dbus and dbus-broker are enabled, we have a conflict with the configuration files, the socket activation file. Also, original dbus activates the daemon as a service in multi-user.target.wants, so it is not socket-activated and dbus-broker would never get the opportunity to start. Therefore, original dbus is updated to remove the conflicting files and the activation of dbus-daemon. Since dbus-broker installs some of the same file that original dbus removes, we have to add a dependency to make sure that the ones installed by dbus-broker aren't removed. If both are installed, it is still possible to revert back to using original dbus as system bus: - at build-time: by calling systemctl enable/disable from a post-build script (preferred), or by providing drop-in units or presets in an overlay (less preferred) or custom skeleton (as a last resort), - at runtime (on a RW filesystem): by calling systemctl enable/disable Note about the user: the path to the system bus socket is a so-called "well-known location": it is expected to be there, by spec. Moving it elsewhere is going to break existing programs. So, the user running the system bus daemon must be able to create that socket. As we may have two packages providing a system bus daemon, they have to be both able to create the socket, and thus must both be able to write in the directory containing the socket. And since they can be switched at runtime, they must be running as the same user. We can't just reference the original dbus user, so we duplicate the entry. What is important, is that the user be named 'dbus', as that's what we use in both cases. If both original dbus and dbus-broker are selected, the dbus user is included twice, but the specifications are identical so that's fine. mkusers will create the user only once. Finally, the licensing terms are pretty trivial for dbus-broker itself, but it makes use of third-party code that it inherits as git submodules (that are bundled in the release archive). Thus the licensing is a bit convoluted... The third-party codes claim to be licensed as "Apache-2.0 and LGP-2.1+" in their AUTHORS files, but at the same time claim "**Apache-2.0** OR **LGPL-2.1-or-later**" in their README files. The individual source files (that are used) do not seem to have any licensing header to clarify the situation. So we represent the situation with "Apache-2.0 and/or LGPL-2.1+". Signed-off-by: Norbert Lange <nolange79@gmail.com> [yann.morin.1998@free.fr: - don't select systemd; depend on it instead - only install config files and systemd units without original dbus - install a user to run the message bus as - fix licensing info - entirely reword and extend the commit log - add myself to DEVELOPERS as well ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> [Arnout: - Use dbus-broker as system bus if both are selected. - Remove conflicting files from dbus installation. - Simplify symbolic link creation. - Add comment to remind update of session.conf and system.conf. ] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-01-09 23:16:47 +01:00
# Locally calculated
sha256 bea7f653e7251063c5f427e9e3f93562d38a0d8667ae6d49fb56f113605985de dbus-broker-32.tar.xz
package/dbus-broker: new package dbus-broker is an alternate implementation of a dbus daemon. It can be used as a drop-in replacement for the system bus daemon, as well as the session bus daemon. dbus-broker is (basically, and as far as we're concerned in Buildroot) split in two components: - the actual message bus daemon, that relays messages across clients - a launcher, which is responsible for setting various aspects of the bus, like setting the policy et al. and opening the socket(s) the message bus daemon will have to listen on... The launcher can only be used in a systemd setup (it makes heavy use of systemd facilities), while the message bus is generic. However, the message bus daemon is useless without a launcher. There does not exist a non-systemd launcher, which makes dbus-broker actually a systemd-only package; this can be revisited when/if a non-systemd launcher appears. Note, however, that libdbus is not provided by dbus-broker. People who want to use dbus-broker as the bus daemon, and need libdbus, will have to enable both. If only original dbus is enabled, things stay as they are now. This is for the moment still the default, though we should change that once dbus-broker has proven to work. If only dbus-broker is enabled, it installs the necessary socket activation units and dbus configuration files. The daemon is not launched at boot time; instead it is socket-activated when a client connects to the bus the first time. If both original dbus and dbus-broker are enabled, we have a conflict with the configuration files, the socket activation file. Also, original dbus activates the daemon as a service in multi-user.target.wants, so it is not socket-activated and dbus-broker would never get the opportunity to start. Therefore, original dbus is updated to remove the conflicting files and the activation of dbus-daemon. Since dbus-broker installs some of the same file that original dbus removes, we have to add a dependency to make sure that the ones installed by dbus-broker aren't removed. If both are installed, it is still possible to revert back to using original dbus as system bus: - at build-time: by calling systemctl enable/disable from a post-build script (preferred), or by providing drop-in units or presets in an overlay (less preferred) or custom skeleton (as a last resort), - at runtime (on a RW filesystem): by calling systemctl enable/disable Note about the user: the path to the system bus socket is a so-called "well-known location": it is expected to be there, by spec. Moving it elsewhere is going to break existing programs. So, the user running the system bus daemon must be able to create that socket. As we may have two packages providing a system bus daemon, they have to be both able to create the socket, and thus must both be able to write in the directory containing the socket. And since they can be switched at runtime, they must be running as the same user. We can't just reference the original dbus user, so we duplicate the entry. What is important, is that the user be named 'dbus', as that's what we use in both cases. If both original dbus and dbus-broker are selected, the dbus user is included twice, but the specifications are identical so that's fine. mkusers will create the user only once. Finally, the licensing terms are pretty trivial for dbus-broker itself, but it makes use of third-party code that it inherits as git submodules (that are bundled in the release archive). Thus the licensing is a bit convoluted... The third-party codes claim to be licensed as "Apache-2.0 and LGP-2.1+" in their AUTHORS files, but at the same time claim "**Apache-2.0** OR **LGPL-2.1-or-later**" in their README files. The individual source files (that are used) do not seem to have any licensing header to clarify the situation. So we represent the situation with "Apache-2.0 and/or LGPL-2.1+". Signed-off-by: Norbert Lange <nolange79@gmail.com> [yann.morin.1998@free.fr: - don't select systemd; depend on it instead - only install config files and systemd units without original dbus - install a user to run the message bus as - fix licensing info - entirely reword and extend the commit log - add myself to DEVELOPERS as well ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> [Arnout: - Use dbus-broker as system bus if both are selected. - Remove conflicting files from dbus installation. - Simplify symbolic link creation. - Add comment to remind update of session.conf and system.conf. ] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-01-09 23:16:47 +01:00
sha256 3cda3630283eda0eab825abe5ac84d191248c6b3fe1c232a118124959b96c6a4 LICENSE
sha256 20ea1f96abc15553695c6725bb3dcabff4b43b85b7ca7d675a2b8860e3b01f87 subprojects/libcdvar-1/AUTHORS
sha256 8153c478102dc209b30dd4627cf5bb3596263f99692bf3eec174b1e17bbf8a3b subprojects/libcdvar-1/README.md
sha256 6d63b1fb794d4c02622595ad30357c90398aa883864e5a275479139c8f03208f subprojects/libcini-1/AUTHORS
sha256 fc92d49d69aa9aa91919bac79242abee3eda27a567b4573ed3690b5cef0cf2fd subprojects/libcini-1/README.md
sha256 a30deb6dde90366bfaf054bc689a209b974f80c1cceac950c4378c14abaa243a subprojects/libclist-3/AUTHORS
sha256 75f4c76441ac69ba9474bb7ad0958389ca0f1f2fc90c5f7b033be3461652f5a6 subprojects/libclist-3/README.md
sha256 23f24eeaaded5fedd6e7840b6f7b73838f9a4e2112ad6a12fe1ef958f73d0214 subprojects/libcrbtree-3/AUTHORS
sha256 05113a24aca4c537819dd0d91b95b13edb85bea4b6a77a6d9269becb397ed374 subprojects/libcrbtree-3/README.md
sha256 6d63b1fb794d4c02622595ad30357c90398aa883864e5a275479139c8f03208f subprojects/libcshquote-1/AUTHORS
sha256 cad109dd33062518a437ebee145ba863fe0e047d4e3db9c28b0bf3c6148f10c2 subprojects/libcshquote-1/README.md
sha256 32913ba08dc041f3f4ca361fc0d68014120e1c612772aabbcc901556df499ce5 subprojects/libcstdaux-1/AUTHORS
sha256 7c4b6c325b0bc02150089112f65132ee999b0f44500b73d1fc06d96c93161037 subprojects/libcstdaux-1/README.md
sha256 7e660796fea0400a1a9a539226c345b3c656a745a334e323e33258de7864e985 subprojects/libcutf8-1/AUTHORS
sha256 106099cc1c488cbf8911f56da7977a955f6b27a7bb5b815985e59d9fae0e6fe7 subprojects/libcutf8-1/README.md