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>
