The base version for uselessd is systemd-208, which is the version used in 13.1. Let's try if a direct substitution of the binaries works and watch out for the problems.
Expected result of the project is to have a working package with "Conflicts: systemd" and "Provides: systemd". The goal is not to fix all problems, a stripped down system with uselessd is considered a good achievement. Anything more complicated could build on top of this.
Hopefully this will bring some technical grounds to the systemd disputes whehter there are working alternatives that do not require to throw away everything that has been adapted to systemd so far.
Looking for mad skills in:
Nothing? Add some keywords!
Activity Show All
Status report after HW
Mission accomplished. Update from systemd to uselessd-4 works, there are some packages that need to be tweaked. There are still problems like not resolving hostname and no networking set up. Both can be fixed manually.
OBS://home:dsterba:project211 contains the packages, uselessd can replace systemd via 'rpm -U'. It's possible that some packages depend on systemd-journal and deny the upgrade. Either uninstall them or pick the versions from the repository.
Most of the work was packaging. Trim systemd.spec until it builds fine. Then go through patches to see what still applies.
Pending and future work:
- package udev separately (partial) - systemd builds only as a whole, so building udev means removing everything else from the build. Not effective, but works.
- replace nss-myhostname functionality
- find out why networking is not-working, probably some start-up dependencies that were removed by uselessd
- see if/what local systemd patches could be upstreamed
More boring future work:
- find more whole-systemd dependencies that rather rely on a particular feature/subsystem like journald, logind
- enhance the packages to enable the features at configure time ** good example: polkit (configurable journal support) ** bad example: rpcbind (pulls systemd, no way to configure out journal, patch is easy though)
- most of the fun here is to convince maintainers of various packages that the autoconf and patching for alternate systemd implementations is a good thing.
I think this could work in long term, all changes seem doable in a way that's already common and everybody is fine with (ifdefs, configure-time changes, spec file defines). Here the good relations between systemd-haters and systemd-lovers will really shine.
The replacements for removed features should be provided in a convenient way (like recommending packages etc).