There is no need to have them as systemd correctly handles reloading
depending on the transaction ordering (even if systemd is installed
_after_ the package that installs the unit file).
Additionally, this also drops hard requires on /usr/bin/systemctl and
just makes the scriptlets that call systemctl conditional on systemctl
being present.
All of this helps avoid pulling in full systemd for container setups.
Make the 'dbus' package pull in 'dbus-broker' over 'dbus-daemon' as the
default implementation. Note that dbus-broker-16-2 is needed, since
this has the required hooks to switch over the systemd units.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
The addition of `Requires: fedora-release` broke all installations
using the non-branded `generic-release` package. This should not be
a requirement, but a conflict against versions older than those
which added the preset.
Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>
Add fedora-release to daemon subpackage, as the systemctl preset calls
in the triggerpostun require it. Add systemd_requires macro to daemon
subpackage, as it (like the common subpackage) calls systemctl in
triggerpostun.
Both subpackages call various %systemd scriptlets, so they need
the %systmd_requires macro. Their %triggerpostun also call
systemctl directly, so add an explicit Requires on that.
Some of this may in practice prove redundant, but let's be explicit
and hopefully more robust.
Signed-off-by: Tom Gundersen <teg@jklm.no>
The 'useradd' invocation is now on the 'daemon' subpackage, so move the
useradd dependency as well.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
The systemd RPM macros only apply presets on first install, we need
to also apply them on the initial upgrade that starts depending on
them.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
As it turns out, 'fedora-release' only has:
'Provides: system-release'
rather than:
'Provides: system-release = %{version}-%{release}'
This means, any explicit dependencies on 'system-release' ignore
versioning completely. This is unfortunate, and breaks our reliance on
'system-release'.
Fortunately, unlike recommended on the wiki, it is safe to depend on
'fedora-release' explicitly. Other fedora flavors have this package as
well, so there is no reason not to.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
The systemd_{post,postun,preun,..} hooks should be called in the package
that actually provides the given files. There is no harm in calling
these in the dbus-daemon package, but preferably we don't. Move this to
'dbus-common' for dbus.socket, since dbus.socket is provided by it. This
makes sure the unit is properly enabled/disabled even without the
dbus-daemon package installed.
Note that it is safe to enable/disable dbus.socket even without a
dbus.service around. systemd can deal with this just fine, and only ever
actually pulls in the socket if an activatable service is around.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Make sure the generic unit files are provided by 'dbus-common', so
alternative dbus implementations can use them as well.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Rather than installing symlinks during the installation manually, put
in [Install] sections into the units. This has the same effect, but
allows changing the installation conditions via systemd-presets, which
are provided by the 'fedora-release' package.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Rather than using the upstream units, use custom units tailored for
Fedora. For now, we mirror what upstream does, but rename the service
to 'dbus-daemon.service', with an alias on 'dbus.service'.
Follow-up patches will then introduce some changes to the units for
better integration of alternative D-Bus implementations.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Create a new sub-package called 'dbus-tools', which includes all the
independent command-line utilities provided by the reference
implementation. They are valid to be used with independent bus
implementations, so no reason to make them pull in dbus-daemon.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Create a new sub-package called 'dbus-common', extracting the XML
configuration and setup files from 'dbus-daemon'. These files might be
used by alternative D-Bus Messages Bus implementations, hence we want
them as a separate package.
This also pulls in the 'dbus' sysuser.d setup file, since this uid is
referenced from the xml-configuration of the system bus. Hence, it is
part of the configuration and required to be used by any compatible
implementation using the official XML configurations.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
This extracts all the contents of the 'dbus' package into a new
'dbus-daemon' package. All internal sub-package dependencies are
updated to point to the new sub-package. The original 'dbus' package is
kept around as empty meta-package that simply pulls in 'dbus-daemon'.
This is meant for compatibility so other packages continue working for
now. Dependencies on 'dbus' will be reviewed and updated before this
meta-package gets removed.
This package rename prepares Fedora to allow alternative
implementations of D-Bus System and Session buses. The 'dbus' package
name is freed from dependencies on any particular implementation.
Instead, the reference implementation is now called 'dbus-daemon' as a
package, with the intent to re-use the 'dbus' package name in the
future as a meta-name provided by 'dbus-daemon' as well alternative
implementations like 'dbus-broker'. It will serve as dependency of
dbus-only services to clearly tell rpm that a dbus system or user bus
implementation is required for a given package.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
