Changing init software after a distribution has been installed
Following the article I wrote on comparing init software and a Questions & Answers column in which we talked about distributions which allow the user to select their distribution's init software, we received the following comment:
How about writing a step-by-step tutorial on taking a distro (say Debian or Slackware), and replacing its default init with another?
It's an interesting idea, swapping out one init implementation for another. In theory, it should be fairly easy to remove one init package and replace it with another. After all, most of the init implementations do approximately the same jobs. However, there are three major obstacles in the way if we want to change the init software our distribution is running.

The first issue is init is a low-level, core component of any Linux distribution. It's only a step above the kernel in terms of being at the foundation of the operating system and it is a key element in booting and shutting down the system. This means we can't just stop the init process, uninstall it, and install a replacement the same way we would change our web browser or music player. This is going to require a reboot, at least, and (if we're running systemd's init) on some distributions the software may not agree to be removed while it is running.

To attempt a car analogy: replacing init is a little like trying to change the wheels of a moving car. It's not as hard as replacing the engine (kernel), but it's going to be more complex than switching the radio station.

The second concern involved is some software these days relies on specific init functions, particularly in distributions which use systemd. For instance, if you are running some of the heavier desktop environments, they may rely on systemd functions. Removing systemd and replacing it with, for example OpenRC, could cause your desktop environment to no longer work. Likewise, if you use Snap packages, removing systemd and using another init implementation would cause Snap programs to cease working. We should make sure we are not using any applications which depend on a specific init package directly before attempting to swap one init for another.

The third challenge is going to be that many distributions do not package more than one init implementation. When we look through the official collection of Slackware packages, Arch packages, and Fedora packages you will start to notice a lack of diversity in this regard. Slackware has a SysV init package, but no entry for systemd or runit. Arch and Fedora offer systemd, but there is no sign of runit or SysV. The Debian family is one of the few parts of the Linux ecosystem where we will find multiple init implementations packaged. Debian uses systemd by default, but also provides SysV, runit, and s6 along with the OpenRC service manager.

A person might think this situation is okay, most init implementations are small, so we can just build the software from source code. Building from source will side-step the need for a distro-provided package. The problem though is the init software itself is one small component in the start-up and shutdown process. We also need a service manager and either unit files, configuration files, or shell scripts to implement service management. These usually need to be provided by the distribution and, if they are missing, init won't really be able to do anything. In other words, if your distribution doesn't provide a package for your desired init software, it also won't have the supporting configuration and script files and this will prevent us from swapping init implementations.

Debian has a wiki entry which talks about init, the various init implementations, and touches on the fact switching init software from systemd to SysV is supported. Switching to other init implementations, such as runit, may be possible, but the wiki warns us runit does not receive the same level of testing and support.

Debian's wiki lays out the steps to switch from systemd (Debian's default init software) to SysV init, the most supported alternative. I'm going to share the steps here with brief explanations.

First, we are asked to clear out the package cache:
apt clean
Cleaning the cache makes it possible to download the packages we will need to install and have only the packages we need to install in the APT cache. Next, we download the packages we need to set up SysV init and its related utilities:
apt update
apt --download-only install sysvinit-core libpam-elogind elogind
The systemd software will cause issues (according to the wiki) if we try to replace it while running in normal mode, so we need to switch to rescue mode. This should probably be done from a terminal and not when logged into a graphical environment as all unnecessary services and applications will be terminated.
systemctl rescue
We may need to enter the root user's password at this time to get a command line prompt.

Next, the wiki tells us to run the APT command to install the packages we downloaded. However, and I want to stress this before sharing the recommended command, this does not work on a fresh copy of Debian 12. It will cause a circular dependency issue and effectively break APT package management until the situation is manually resolved. This is the suggested command:
apt install /var/cache/apt/archives/*.deb
While the above command fails and causes dependency issues, there is another, similar command which will work to install SysV and its related programs. The proper commands are as follows:
dpkg -i /var/cache/apt/archives/*.deb
apt-get -f install
At this point we can run the init command to confirm we have SysV init installed:
/sbin/init --version
SysV init version: 3.06
Assuming the output of the above command correctly shows SysV init is installed, we can then reboot. I tested the above steps on a fresh copy of Debian 12 running the LXQt desktop and confirmed the process worked. This is, in part, due to the sysvinit-core Debian package pulling in the necessary supporting scripts and packages as dependencies. While I've only tested this process on Debian, it should work for most members of the Debian family, assuming your desktop environment and package manager do not reply on systemd. Ubuntu ships both GNOME as its desktop and Snap as its package manager and swapping out systemd will likely break both of these key components.