[Dev] [RFC] OpenRC strategy

[Luke Shumaker]

I haven't really been a part of Parabola's OpenRC scene, but given my
maintainership of notsystemd, I probably should be.

I have a couple of issues with how openrc and friends are being
packaged right now.

 - I'm locked in to using openrc-init as PID 1.  OpenRC is designed in
   a way that splits PID 1 ("init") from the system manager (yay small
   modular programs!).  That means you can actually use it with a
   number of different init programs, including sysvinit, busybox
   init, and since OpenRC 0.25, openrc-init.  I should be able to use
   any of those as my init--hell, I should even be able to use systemd
   as my init.

   I propose that openrc be turned in to a split package, something like:

       pkgname=(openrc openrc-init openrc-sysvinit)

       package_openrc() {
         depends=(openrc-init)
         ...
       }

       package_openrc-init() {
         depends=(openrc)
         conflicts=(sysvinit)
         ...
       }

       package_openrc-sysvinit() {
         depends=(openrc sysvinit)
         provides=(openrc-init)
         conflicts=(openrc-init)
         
         install -Dm644 support/sysvinit/inittab "${pkgdir}/etc/inittab"
       }

   From there, there could be other [pcr] packages like
   'openrc-busybox-init' to use busybox init.  These packages would
   need to depends=(openrc), provides=(openrc-init), and probably
   conflicts=(openrc-init).

   Unfortunately, we don't have a good meta-package name to conflict
   with other packages that provide /bin/init.

 - (not)systemd-udev should be a just as valid of a choice for udev as
   eudev is.  In the past this was the case, via the udev-openrc
   package.  If this package needs to be merged in to the notsystemd
   package, I am fine with that.

-- 
Happy hacking,
~ Luke Shumaker