Linux From Scratch ends SysVinit support

>>cf100c+(OP)
All I want is init scripts and X11, but the horizons are shrinking. I've already compromised with systemd, and I don't like it. I see BSD in my future, or at least a linux distro from the list here https://nosystemd.org/ - probably Gentoo. Nothing to stop me, absolutely nothing at all. I just need a few days free to backup/wipe/reinstall/reconfigure/restore_data and I'll be good. Better make that a few weeks. Maybe on my next machine build. It's not easy, but I build machines for long term use.

As for Linux from Scratch - This is something that's been on my radar, but without the part I'm truly interested in (learning more about SysV) then I'm less inclined to bother. I don't buy the reason of Gnome/KDE - isn't LfS all about the basics of the distro than building a fully fledged system? If it's the foundation for the other courses, but it still feels weak that it's so guided by a future GUI requirement for systemd when it's talking about building web servers and the like in a 500Mb or less as the motivation.

>>antony+Qc
OpenRC on Gentoo works great. I have a full bleeding edge Wayland KDE Plasma with Pipewire setup that I game on.

OpenRC recently added user "units" aka services running as a user after a session start. Something that many new GUI user space applications rely on for various things.

There are growing pains. https://bugs.gentoo.org/936123

Especially when upstream hard requires systemd. More annoying when there's no real reason for it.

But there is a way forward and I highly recommend people try to build software to work without systemd before assuming it's always there.

>>hparad+Th
To pile on, a minimal OpenRC service file is just as complicated as a minimal SystemD service file; that is, they're both almost-exclusively composed of key-value pairs. For instance, this is the service file for the 'rsyncd' service [0]:

  #!/sbin/openrc-run
  
  command="/usr/bin/rsync"
  command_args="--daemon ${RSYNC_OPTS}"
  pidfile="/var/run/${SVCNAME}.pid"
  
  depend() {
   use net
  }

Like SystemD, OpenRC provides pre/post start/stop hooks that you can use to call out to other programs.

Unlike SystemD if you need to make nontrivial decisions at service-status-management time, you have the option of putting your scripts or calls to other programs inline, rather than hoping that SystemD gives you the hooks you need in the places you need them and passes in the data you require. [1]

[0] And if 'rsyncd' was supervised with 'supervise-daemon', you wouldn't need to specify the location of the pidfile.

[1] As a trivial example, you can dynamically depend on other services depending on system configuration (as PostgreSQL does). As a less-trivial example, you can check for and warn the administrator about common service misconfigurations with the same mechanism that provides service startup and status information (as several services do).

>>simonc+RX1
> As a trivial example, you can dynamically depend on other services depending on system configuration (as PostgreSQL does)

Depending on what you want to do, a generator might be appropriate:

> Their main purpose is to convert configuration and execution context parameters that are not native to the service manager into dynamically generated unit files, symlinks or unit file drop-ins

zlacker