Closed LW-archlinux closed 7 years ago
I don't quite understand your question. Can you elaborate a bit more on what these distros are doing differently?
@williamh
Arch guys use SYSCONFDIR=/etc/openrc, whereas manjaro use default /etc, which makes in fcat arch and manjaro openrc packages incompatible. I have made ages ago the proposal to use default SYSCONFDIR=/etc on arch as well, but no success. It supposedly clashed with systemd, which it does not. In my view, its a packaging issue.
I don't see how this has anything to do with run-time vs build-time configuration. In order to be able to use service files from the various projects simultaneously, OpenRC would need to be able to use multiple configuration directories regardless of when they are configured.
My opening post was indeed way to vague and i wasted your times.
Attempt to clarify :
Last weekend i was working on upgrading arch linux openrc pacakge from 0.22.3 to 0.24 . While working on the new opentmpfiles packages I used gentoo ebuild and manjaro PKGBUILD as examples.
I noticed a few things : init.d service files are hardcoded to use #!/sbin/openrc-run gentoo ebuild does use this, both manjaro and arch linux PKGBUILDs change the initd file to use #!/usr/bin/openrc-run
gentoo ebuild and manjaro PKGBUILD put service files in /etc/conf.d and /etc/init.d , while arch linux PKGBUILD puts them in /etc/openrc/conf.d & /etc/openrc/init.d .
I looked at this as a packager and thought how a template package usable for all openrc distros might look. At buildtime of a servicefile package two data are needed : the location of openrc-run and that for the configuration folders This could be figured out by checking the existence of command & folders in often used locations, but that is prone to errors. Otoh, if openrc is running it knows the exact values for these 2 locations.
Upon installation , openrc could put a script exporting 2 variables (ex: openrc_sbindir and openrc_confdir ) in a location like /etc/.profile.d so it will be executed every boot.
A template for a servicefile package in pseudocode would then look something like this :
IF NOT openrc_sbindir THEN echo "openrc not installed, aborting"
IF openrc_sbindir NEQ "/sbin" THEN adjust initd-file
copy confd-file to openrc_confdir/conf.d/
copy initd-file to openrc_confdir/init.d/
IF auto-enabling_is_wanted THEN
openrc_sbindir/rc-update add <service> <runlevel>
I lack the xp with and insight in openrc to know if this is a good solution, but it does solve the issues i noticed.
@udeved : In my opinion this is a genuine issue and solving it will improve openrc. please treat it like that.
Links https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/opentmpfiles/opentmpfiles-0.1.3.ebuild https://github.com/manjaro/packages-openrc/blob/master/opentmpfiles/PKGBUILD https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=opentmpfiles
So you want to be able to query build-time configuration settings at run-time in order to use them in a PKGBUILD so that the PKGBUILD, not the built package, can be shared across distro's?
@LW-archlinux
I find it just a bit sledge hammer to solve this problem. If we could only agree to use default /etc, our packages would be fully compatible.
PS: What's the reason behind SYSCONFDIR=/etc/openrc? If its for the sake of allowing old initscripts being installed in parallel, why not make them conflict and be done with it, ie SYSCONFDIR=/etc?
@andrewgregory : that is indeed the idea. If setup correctly, it could work with rpm source packages , all distros that support the gentoo ebuild format and such. Maybe debian/ubuntu based distros and BSDs would also benefit.
@udeved : compatibility with other init systems is the most important factor imo. On arch linux i can have runit, systemd, openrc and sysvinit installed at the same time . Choosing which is started is done through init= lines in the bootloader.
I boot into openrc 99% of the time, but do have a few usecases where i need to boot into one of the others. So i do have a personal interest in keeping openrc on archlinux compatible with other init systems.
Its a matter of taste I think, I would maintain, a user should decide, which init is being installed, a decision between choices the user has to make.
@LW-archlinux I do also believe something like this could be beneficial to make setup a little bit easier. It would make less work for packagers.
@udeved I ran into the same problem with init.d being in /etc. There was a conflict with other init systems if I had more than one installed at a time. I started work on a new distro based on linux from scratch that uses pacman for the package manager and sysvinit/openrc as it's primary init system. It does also have lfs bootscripts in it which conflict with /etc/init.d, so in my distribution the solution was to move openrc into /etc/openrc/init.d otherwise I couldn't have both lfs bootscripts and openrc installed at the same time. Thanks to the separation I now have sysvinit, lfs bootscripts, s6, and runit all working together for init and I have openrc, lfs bootscripts, s6 scripts, and runit scripts to handle services, supervision, and rc. They all can coexist if I stick openrc in "/etc/openrc/init.d". You are right about init.d not conflicting with systemd, but it does conflict with arch bootscripts and lfs bootscripts and pretty much any other boot method that uses init.d as it's location to store scripts.
@cromerc
Yes, I know, my point is, you also can't have systemd and eudev installed at same time, its a choice to make.
@LW-archlinux any service scripts written outside of openrc should have a shebang line that looks like #!/sbin/openrc-run in order to have the widest compatibility. Think of this as how we write shell scripts; we don't put sh in /usr/bin and request that everyone change all of their shell scripts to have a #!/usr/bin/sh shebang.
Regarding the location of service scripts (/etc/init.d), I think the cost of changing the default would be very high at this point; it would require a lot of work for users and packagers, so I would have to preserve the default as-is.
I would like other input before I make a decision on what to do with this, I am hesitant to change the location of service scripts.
@williamh
As for shebang line, default #!/sbin/openrc-run doesn't work on arch, the service won't be recognized, because of /usr merge. If there was to change something in locations, it should probably be two new variables $SYSCONFDIR/$INITDIR and SYSCONFDIR/$CONFDIR ? This way, SYSCONFDIR would still point to /etc by default.
The shebang line doesn't work on the distro I am making either because of the merged /usr folder. I had to rewrite them to #!/usr/bin/openrc-run otherwise openrc looses track of the services.
Apparently openrc can't handle the symlinks correctly which forces us to change the shebang line.
My understanding of the usr merge is that /bin, /sbin and /usr/sbin all are symbolic links to /usr/bin, correct?
Thats correct, however, if we don't sed the shebang, the service won't be detected by openrc. I painfully found out once, when I forgot to sed older version of the udev scripts. Btw, any chance the get merged in openrc as optional make?
Correct. But openrc fails to follow the symlinks. So as a work around we were forced to change the shebang lines to /usr/bin/openrc-run If we don't change them the service dissapears completely from openrc and stops running.
I need to know more about what breaks if symlinks are used. The shebang lines are not being interpreted by OpenRC; those are interpreted by the kernel.
What ends up happening is that if I type the command rc-status, the service has disappeared completely it is invisible. It does not show started, stopped, crashed or any other status. The service also is not running in the background, so either it never started or it stopped immediately after being run. If you want to try it out you can test this with this ISO: https://sourceforge.net/projects/archopenrc/files/arch-openrc/archlinux-openrc-2017.03.01-x86_64.iso/download When the ISO boots you can change the shebang lines in the service scripts to play around and witness the problem.
Can you link to the PKGBUILD that built the openrc on that ISO?
Hmmm I just tried it again, this time the service didn't crash and is still running the background. But it still went invisible and is not showing up in rc-status. I tested by changing the shebang line on sshd. Maybe it is just certain scripts that crash not all of them.
If you have the /usr merge symlinks in place, you don'5t need to set prefix or sbindir in your pkgbuild.
Without the prefix and sbin options the package is invalid and can't be installed on arch linux because of a /bin and /sbin conflict. Should I just manually move the stuff from bin and sbin into /usr/bin during the packaging then?
At present, gendepends.sh checks that the shebang line of the initscript matches @SBINDIR@/openrc-run (or runscript, but that's deprecated), and if not, it gets skipped, and not added to the deptree; rc-status then skips it because it's not in the deptree. That's why things disappear when you change their shebang (and services that have needed dependencies will crash because those dependencies aren't started). A fix that wouldn't require manually moving things around during package() in the PKGBUILD would be to set up the /usr merge symlinks in the pkgdir before make install, and then remove them after. Then remove the setting of PREFIX, SYSCONFDIR, and SBINDIR, and you should probably set LIBEXECDIR to /lib/rc (If /lib64 is a thing on amd64, use that instead of /lib on amd64).
We'll probably remove the shebang check from gendepends.sh, but that's still being discussed at this moment.
Alright, I will start repackaging everything with those changes. Thanks.
Thanks a bunch, everything works fine now with the standard #!/sbin/openrc-run shebang line. I rebuilt all my packages. The big problem now is the Arch Linux AUR... hopefully everyone will update their openrc scripts.
arch linux , systemd-free.org and manjaro use different locations for openrc. Using SYSCONFDIR and BINDIR , we can set the correct location at build time.
Packages providing openrc service files for arch linux can not be used on systemd-free.org , manjaro and vice versa. If the locations needed for services could be detected at openrc runtime, it should be possible to create packages that work on all systems that share a package manager / package build system..
Is there a way to achieve this ?