is systemd required?

[theangrygrunt]

I'm curious about how feasible a port to non systemd based distros is. I am aware that what this was forked from gentoo-unity which requires systemd but I'm not sure if anything has changed with that requirement.

[c4pp4]

Systemd is required by upstream packages, such as unity-base/unity-settings-daemon, some indicators etc. I think you can rewrite systemd services to any other init system, but I'm not going to do that as I have no time to maintain it. It use to be Upstart. As of Ubuntu 15.04 it's systemd.

[EarldridgeJazzedPineda]

Systemd is required by upstream packages, such as unity-base/unity-settings-daemon, some indicators etc.

• unity-base/unity-settings-daemon doesn't need systemd, as far as I know.
• unity-indicators/indicator-datetime is the only indicator to hard-depend on systemd-related D-Bus services (specifically, it depends on org.freedesktop.timedate1), but that can be fixed with app-admin/openrc-settingsd.
• The only component of Unity that hard-depends on systemd is unity-extra/unity-greeter, which calls systemctl at runtime to load the indicators. slick-greeter can be used as a substitute for the Unity greeter, which bundles all of the indicators and doesn't require systemd.
• At configure time, unity-base/hud and unity-base/unity look for a variable called systemduserunitdir within the systemd pkg-config file. But not all Linux distributions have this file, so in that case, CMake errors out with install FILES given no DESTINATION!. This can be fixed by patching the CMakeLists.txt file, by replacing:
  pkg_get_variable(SYSTEMD_USER_DIR systemd systemduserunitdir)
  with:
  set(SYSTEMD_USER_DIR "${CMAKE_INSTALL_PREFIX}/lib/systemd/user")

I am not a Gentoo user, though. I am making packages for Void Linux.

[c4pp4]

@EarldridgeJazzedPineda I meant not only hard-depends, but also packages providing systemd service files.

[EarldridgeJazzedPineda]

The Void Linux team recommends that systemd unit files be left in packages as-is, so that they can be used as a reference point to make runit services. Just about anything can be a "service" in systemd, but runit isn't designed to handle desktop environments, panel indicators, etc. So instead of relying on the init system to load Unity, I decided to self-contain the desktop components into a custom GNOME session, similar to what i3slkiller did when he/she tried to make Unity working in Porteus.