OpenRC & eudev on Arch

x33a · 2013-12-13 18:01:38

@ artoo, but "killprocs" explicitly calls killall5. Is this provided by runit as well? According to progandy, busybox does provide it though.

Last edited by x33a (2013-12-13 18:29:24)

artoo · 2013-12-13 18:12:28

x33a wrote:

@ artoo, but "killprocs" explicitly calls killall5. Is this provided by runit as well? According to prograndy, busybox does provide it though.

Uhm, I suppose so, I tested runit a while back, but found it too rc-ish for the purpose.
As far as I remember, runit is more than sysvinit replacement, in fact it is a whole init system.

Maybe I got you wrong, but what is the problem exactly?

If the AUR sysvinit version would not run, a working version could be provided any time, since sysvinit-tools was just split out sysvinit stuff. As I see it, it is a matter of fiddling with sysvinit, but current AUR version works for me.

Btw, runit is also in AUR.

Last edited by artoo (2013-12-13 18:21:13)

Gusar · 2013-12-13 18:22:52

busybox killall5 does not filter out kernel processes though. You need this patch for that: https://bbs.archlinux.org/viewtopic.php … 0#p1319380

I just sent that patch to the busybox mailing list.

x33a · 2013-12-13 18:31:39

artoo wrote:

Maybe I got you wrong, but what is the problem exactly?
If the AUR sysvinit version would not run, a working version could be provided any time, since sysvinit-tools was just split out sysvinit stuff. As I see it, it is a matter of fiddling with sysvinit, but current AUR version works for me.

Yeah, the problem was solved when I updated sysvinit. It was updated to provide killall5 recently.

Gusar wrote:

busybox killall5 does not filter out kernel processes though. You need this patch for that: https://bbs.archlinux.org/viewtopic.php … 0#p1319380
I just sent that patch to the busybox mailing list.

Great!

artoo · 2013-12-16 16:49:04

I made the openrc-base pkg in AUR somewhat dynamic concerning additional features.
In fact, the pkgbuild emulates gentoo use flags.

This way, it is very easy to build openrc-base with or without udev support, or to switch between oldnet-netnet make args.

At top of pkgbuild, there is this:

# set vars: 0=off; 1=on
_use_netifrc=1
_use_udev=1
_use_kmod=1
_use_scripts=1

Thats all, posted just to document the changes.

x33a · 2013-12-16 17:09:34

Maybe you can provide an eudev variable too. (Which will need to conflict with udev).

artoo · 2013-12-16 17:12:02

x33a wrote:

Maybe you can provide an eudev variable too. (Which will need to conflict with udev).

How do you mean?

openrc-base provides udev scripts, which also work with eudev.
openrc-base depends on udev, provided by either systemd or eudev.

For eudev, I uploaded eudev-openrc to AUR, which provides the eudev-postmount script.
It is an optional depend of eudev.

Do you mean to merge eudev-openrc into openrc-base? I thought about that.

A general note, the trouble with arch and systemd is, that there is no split out udev pkg from systemd source.
A nice solution was to simply put a udev pkg in the repos, and make systemd depend on it. This would be very friendly to switching to alternative init systems, instead of compiling several important packages against eudev..
But, is simply easier to create an eudev build than splitting out udev from systemd. Something that was promised not happen after systemd/udev merge, but it did.
So, eudev is a valuable fork, ironically much more on non gentoo systems, such as arch.

Last edited by artoo (2013-12-16 17:32:20)

falconindy · 2013-12-16 17:52:26

artoo wrote:

A nice solution was to simply put a udev pkg in the repos, and make systemd depend on it. This would be very friendly to switching to alternative init systems, instead of compiling several important packages against eudev..
But, is simply easier to create an eudev build than splitting out udev from systemd. Something that was promised not happen after systemd/udev merge, but it did.

Your historical record is inaccurate. It was promised that you'd be able to run udev separately from systemd. This is still true today and will be for the forseeable future. No promises were ever made about the ability to build udev separately from systemd. Feel free to see what LFS is doing with disfiguring the build system into something that builds udev only (assuming this still exists).

Separating udev from systemd is a little more reasonable these days now that udev no longer has a runtime ELF dependency on systemd libraries (meaning you'd have a circular dependency between the two packages).

Last edited by falconindy (2013-12-16 17:54:24)

artoo · 2013-12-16 18:11:55

falconindy wrote:

artoo wrote:
A nice solution was to simply put a udev pkg in the repos, and make systemd depend on it. This would be very friendly to switching to alternative init systems, instead of compiling several important packages against eudev..
But, is simply easier to create an eudev build than splitting out udev from systemd. Something that was promised not happen after systemd/udev merge, but it did.
Your historical record is inaccurate. It was promised that you'd be able to run udev separately from systemd. This is still true today and will be for the forseeable future. No promises were ever made about the ability to build udev separately from systemd. Feel free to see what LFS is doing with disfiguring the build system into something that builds udev only (assuming this still exists).
Separating udev from systemd is a little more reasonable these days now that udev no longer has a runtime ELF dependency on systemd libraries (meaning you'd have a circular dependency between the two packages).

My apologies for inaccuracy, but doesn't "run separately" imply an easy make mechanism too?
I guess it comes down to a vague statement, and I won't lose much sleep over this.

In the case of udev splitting,it works on gentoo too, and, arch builds still depend on udev via provides, luckily.
If you want systemd on gentoo, udev remains installed.

My point was, after I read some eudev discussion on gentoo too, that eudev is a valuable fork, simply for providing what was removed from systemd source. A makefile for udev.
Probably not really the original intention of the fork, as it is no real gain on a gentoo system over plain udev.

falconindy · 2013-12-16 18:18:02

artoo wrote:

My apologies for inaccuracy, but doesn't "run separately" imply an easy make mechanism too?
I guess it comes down to a vague statement, and I won't lose much sleep over this.

I can't possibly see how one might reach this conclusion. One can easily 'make systemd-udevd' from the root of a systemd tarball, but your're on your own for the installation of this binary, all the rules, builtins, hwdb files, libudev, udevadm, documentation, gudev...

artoo wrote:

My point was, after I read some eudev discussion on gentoo too, that eudev is a valuable fork, simply for providing what was removed from systemd source. A makefile for udev.

Even the people who work on eudev have clearly stated that it's nothing more than a "training project":

https://archive.fosdem.org/2013/schedule/event/eudev/

artoo · 2013-12-16 18:29:21

falconindy wrote:

artoo wrote:
My apologies for inaccuracy, but doesn't "run separately" imply an easy make mechanism too?
I guess it comes down to a vague statement, and I won't lose much sleep over this.
I can't possibly see how one might reach this conclusion. One can easily 'make systemd-udevd' from the root of a systemd tarball, but your're on your own for the installation of this binary, all the rules, builtins, hwdb files, libudev, udevadm, documentation, gudev...
artoo wrote:
My point was, after I read some eudev discussion on gentoo too, that eudev is a valuable fork, simply for providing what was removed from systemd source. A makefile for udev.
Even the people who work on eudev have clearly stated that it's nothing more than a "training project":
https://archive.fosdem.org/2013/schedule/event/eudev/

I know.
I guess it is a different understanding what a half baked but later applied "runs separately" means.

You just said it, it is not very friendly to encourage a possible separate use, in my opinion.

But lets put this aside, I just find it ironic, that a training project turns out to be a viable solution to a problem.

The maintainer of udev on gentoo is not really happy with eudev, and considers it pointless on gentoo.

x33a · 2013-12-17 05:22:39

artoo wrote:

x33a wrote:
Maybe you can provide an eudev variable too. (Which will need to conflict with udev).
How do you mean?
openrc-base provides udev scripts, which also work with eudev.
openrc-base depends on udev, provided by either systemd or eudev.

Ah, in that case, it is fine as it is.

Do you mean to merge eudev-openrc into openrc-base? I thought about that.

You could do that if it's still possible to use udev for the ones that prefer it.

artoo · 2013-12-17 16:36:55

x33a wrote:

You could do that if it's still possible to use udev for the ones that prefer it.

Have a look, I did:

https://github.com/udeved/pkgbuilds/blo … e/PKGBUILD

Anyway, its kind of useless feature, but doesn't hurt either, since I submit the build with eudev=0.

The only thing to be done, is to make the build not depending on udev, if use_udev=0.

x33a · 2013-12-18 05:05:39

Great!

artoo · 2013-12-18 13:18:28

I made a new pkgbuild for all openrc services, as of now in the split AUR packages, which also has "use flags".

This means, this new package will likely replace the split packages, so the idea.
However, the AUR user needs to set the "use flags"(install switches), to customize the package to his needs, as it is difficult to find a default setting for about 70 services. I tend to set almost everything to zero by default, and make the description pointing it out.
It would only install services really needed and explicitly wanted.

progandy · 2013-12-18 13:37:40

artoo wrote:

I made a new pkgbuild for all openrc services, as of now in the split AUR packages, which also has "use flags".
This means, this new package will likely replace the split packages, so the idea.
However, the AUR user needs to set the "use flags"(install switches), to customize the package to his needs, as it is difficult to find a default setting for about 70 services. I tend to set almost everything to zero by default, and make the description pointing it out.
It would only install services really needed and explicitly wanted.

What do you think about introducing a configuration file which is sourced in the PKGBUILD, remembering to set the switches if you have many services might be cumbersome. maybe something like /etc/makepkg/openrc-services.rc.

x33a · 2013-12-18 13:48:03

progandy wrote:

What do you think about introducing a configuration file which is sourced in the PKGBUILD, remembering to set the switches if you have many services might be cumbersome. maybe something like /etc/makepkg/openrc-services.rc.

I have never heard of /etc/makepkg directory. Can you provide a reference to it?

artoo · 2013-12-18 13:52:32

progandy wrote:

artoo wrote:
I made a new pkgbuild for all openrc services, as of now in the split AUR packages, which also has "use flags".
This means, this new package will likely replace the split packages, so the idea.
However, the AUR user needs to set the "use flags"(install switches), to customize the package to his needs, as it is difficult to find a default setting for about 70 services. I tend to set almost everything to zero by default, and make the description pointing it out.
It would only install services really needed and explicitly wanted.
What do you think about introducing a configuration file which is sourced in the PKGBUILD, remembering to set the switches if you have many services might be cumbersome. maybe something like /etc/makepkg/openrc-services.rc.

Good point, I also was thinking along these lines.

But, if you want to use a sourced config file, you got to make sure the user already has the config in his filesystem when using the AUR build.
I think this is not trivial, because my idea was a wrapper for makepkg to accept use flags(like emerge on gentoo). This would require a "use flag" file structure with predefined flags the wrapper and pkgbuild can read from.
In my opinion, it would be quite some work, testing, maintaining flags etc.

A positive result was, eg being able to build packages containing services with either systemd or openrc use flag.

Last edited by artoo (2013-12-18 13:56:17)

progandy · 2013-12-18 14:06:42

artoo wrote:

But, if you want to use a sourced config file, you got to make sure the user already has the config in his filesystem when using the AUR build.
I think this is not trivial, because my idea was a wrapper for makepkg to accept use flags(like emerge on gentoo). This would require a "use flag" file structure with predefined flags the wrapper and pkgbuild can read from.
In my opinion, it would be quite some work, testing, maintaining flags etc.
A positive result was, eg being able to build packages containing services with either systemd or openrc use flag.

My idea was simpler. Don't let packages share useflags, each package has its own flags and its own configuration file. Do it just like openrc-base, just add a line to source the config after the _use_FOO switches if it exists:

_use_foo=0
_use_bar=0
[ -f "/.../$pkgname.config" ] && source "/.../$pkgname.config"

I have never heard of /etc/makepkg directory. Can you provide a reference to it?

It doesn't exist. I just invented it as a possible common place for system-dependent configuration for PKGBUILDs.

Last edited by progandy (2013-12-18 14:09:52)

artoo · 2013-12-18 14:10:19

progandy wrote:

A positive result was, eg being able to build packages containing services with either systemd or openrc use flag
My idea was simpler. Don't let packages share useflags, each package has its own flags and its own configuration file.

Yes, but wouldn't such thing be better suited in the code for the pacman db?
Say this info gets written as .use in <repo>.db.tar.xz?

PS: A default config for services could be provided by openrc-base, but I think, we should develop some standard for such build config, and split the config to a separate package, so that it can be of general use.

I am about to try this with the PKGBUILD:

#!/bin/bash

import(){
	# $1: build config
        local name=$1
        local config="/etc/makepkg.d/${name}.cfg"
	[[ -f ${config} ]] && . ${config}
}

PKGBUILD:

LIBDIR='/usr/lib/makepkg-use-api'

. "${LIBDIR}/import-functions.sh"

import operc-services

(...)

Last edited by artoo (2013-12-18 23:09:53)

jbernardo · 2014-02-24 08:49:26

Artoo,
What is the status of this? I mean, for someone who wants to switch away from systemd, what would be the best way to install openrc, which aur packages should I choose?
As I can see the options are:
-Openrc
-Openrc-git
-Openrc-base + split packages

I've started with openrc-git, but it is missing a few init scripts (in particular those in the openrc-desktop split package).

I've now trying openrc-base + split packages, but some stuff seems to be missing, like dbus-openrc and device-mapper-openrc, listed as depends for openrc-net-split. I only found out after trying to build openrc-sys-split that they are in this package (which is failing due to mismatched sha256sums for init.d-r3 and dmeventd.initd-2.02.67-r1.

Some more issues - openrc-net-split won't build if ntp and connman are build dependencies, as there is are circular conflicts.

Last edited by jbernardo (2014-02-24 09:18:24)

WonderWoofy · 2014-02-24 16:33:54

@jbernardo, This wiki page seems active...

Lone_Wolf · 2014-02-24 17:15:47

Jbernardo, there are 2 implementations for openrc on arch :

- 1 set is maintained by apg and includes openrc & openrc-git
uses /etc/openrc for configuration

- a 2nd set is maintained by artoo, openrc-base
uses /etc for configuration

AFAICT the 2 implementations can't share init scripts to start services due to the different structure.

The wiki page is mostly written by people that use apg packages, although the info should be useful for people using artoo packages also.

jbernardo · 2014-02-24 17:26:06

@Lone_Wolf: Thank you. It seems like apg packages are more up to date, but less complete. Artoo's didn't build for me without several tweaks - sha2sums, conflicts, etc.
I guess I'll have to "roll my own", based probably on apg's packages.

x33a · 2014-02-24 18:18:54

@ jbernardo

If you are having trouble with a lack of service files, you can simply grab one from artoo's packages and manually place them in the appropriate directory.

You can even find several ones upstream (gentoo), but they will need to be modified a bit (/run, /usr/bin, etc.) for use with Arch.

And lastly, you can find some here as well -> https://github.com/notfoss/archlinux-openrc-services

Arch Linux

#251 2013-12-13 18:01:38

Re: OpenRC & eudev on Arch

#252 2013-12-13 18:12:28

Re: OpenRC & eudev on Arch

#253 2013-12-13 18:22:52

Re: OpenRC & eudev on Arch

#254 2013-12-13 18:31:39

Re: OpenRC & eudev on Arch

#255 2013-12-16 16:49:04

Re: OpenRC & eudev on Arch

#256 2013-12-16 17:09:34

Re: OpenRC & eudev on Arch

#257 2013-12-16 17:12:02

Re: OpenRC & eudev on Arch

#258 2013-12-16 17:52:26

Re: OpenRC & eudev on Arch

#259 2013-12-16 18:11:55

Re: OpenRC & eudev on Arch

#260 2013-12-16 18:18:02

Re: OpenRC & eudev on Arch

#261 2013-12-16 18:29:21

Re: OpenRC & eudev on Arch

#262 2013-12-17 05:22:39

Re: OpenRC & eudev on Arch

#263 2013-12-17 16:36:55

Re: OpenRC & eudev on Arch

#264 2013-12-18 05:05:39

Re: OpenRC & eudev on Arch

#265 2013-12-18 13:18:28

Re: OpenRC & eudev on Arch

#266 2013-12-18 13:37:40

Re: OpenRC & eudev on Arch

#267 2013-12-18 13:48:03

Re: OpenRC & eudev on Arch

#268 2013-12-18 13:52:32

Re: OpenRC & eudev on Arch

#269 2013-12-18 14:06:42

Re: OpenRC & eudev on Arch

#270 2013-12-18 14:10:19

Re: OpenRC & eudev on Arch

#271 2014-02-24 08:49:26

Re: OpenRC & eudev on Arch

#272 2014-02-24 16:33:54

Re: OpenRC & eudev on Arch

#273 2014-02-24 17:15:47

Re: OpenRC & eudev on Arch

#274 2014-02-24 17:26:06

Re: OpenRC & eudev on Arch

#275 2014-02-24 18:18:54

Re: OpenRC & eudev on Arch

Board footer