|
|
|
|
|
by lmm
3799 days ago
|
|
The evil part is that it's making it harder and harder to use a lot of OSS projects on non-Linux OSes. As a FreeBSD user I'm worried, and when it comes to Debian/kFreeBSD the world really has ended as far as I can tell ( and just when it was starting to look like a first-class architecture :'( ). The conspiracy theory would be that it's a deliberate RedHat effort to cripple competitors like Solaris. Unfortunately \*BSD and freedom will be caught in the crossfire. |
|
You need not be.
One of the lirc maintainers a few months ago moved all Debian support out from the main source tree (http://sourceforge.net/p/lirc/git/ci/44696400eb92de342444665...) and this month proposed dropping its System 5 rc scripts (which is what Debian still packages up and uses for running lirc even in "unstable" and "testing", incidentally) and providing only systemd service and socket units.
The issue of Debian kFreeBSD came up. As an exercise, I took the FreeBSD binaries for lirc, which I built from the FreeBSD port, ran the service and socket units through the conversion utilities in the nosh toolset, and (after selecting "ideal" mode and fixing a bug) the converted services successfully supervised the FreeBSD binary under the nosh service manager. This was on actual FreeBSD: on PC-BSD version 10.2, specifically. Even in a world where its maintainers provided only systemd ancillaries, lircd could be run on FreeBSD.
The bug was in the lircd units themselves that the lirc maintainers were wanting to switch to, ironically. lircd is putting stuff in an ephemeral runtime directory /var/run/lirc , without either making the directory itself or declaring it with a RuntimeDirectory=lirc directive in the systemd service units. I simply added RuntimeDirectory=lirc .