You are not logged in.
And I plan to help flesh out other articles soon on there so my fellow Arch/Archbang users who, like myself, are interested in alternatives have decent documentation to follow. I encourage others to follow suit if you have something to share.
This sounds very good.
Openrc wiki entry could use some love, pointing out some of the difference between the openrc versions in AUR.
Offline
Artoo,
I'll be happy to do so, if you can tell me what the differences between the OpenRC packages you offer and the other OpenRC packages. Have you and the other package maintainer suggested merging your packages so that we don't confuse newbie users wanting to use OpenRC?
Offline
Artoo,
I'll be happy to do so, if you can tell me what the differences between the OpenRC packages you offer and the other OpenRC packages. Have you and the other package maintainer suggested merging your packages so that we don't confuse newbie users wanting to use OpenRC?
I tell you what my package does, since I am not up to date if apg changed something.
My package is a tiny bit more vanilla gentoo.
I use default network management scripts(netifrc), gentoo uses by default.
Gentoo manuals and wiki refer to netifrc for networking.
My package is udev enabled, it provides udev scripts and sets proper runlevel.
I make use of standard syvinit from AUR.
The build is easily customizable in terms of which network scripts or if eudev support instead of udev(via systemd). Just change the switches at the top of build.
I maintain a default $sysconf dir, which would be /etc, as opposed to apg /etc/openrc.
This difference makes our packages incompatible, we couldn't agree on merge.
Hence, all scripts my packages provide, may not run with apg version, since some of them define a /etc/foo dir or file.
Last edited by artoo (2014-04-09 21:13:24)
Offline
To answer Mr. Green's question I just added dhcpcd to the default runlevel like so,
# rc-update add dhcpcd default
That works to start dhcp, so that works. netcfg is what I use for network management on my laptop, though.
This is one way.
You can also enable hotplug in /etc/rc.conf
Then set up in /etc/conf.d/net the connection. The default file is well documented.
Example, assuming eth0 to be wired netinterface:
/etc/conf.d/net
dns_domain_lo="foonet"
config_eth0="dhcp"
Netnetworkinface will be auto started and configured with dhcp. You wouldn't need the dhcpcd running or in runlevel. you can also set a modules variable in that file, which selects the dhcp, eg udhcp, dhclient or dhcpcd(default)
Offline
Artoo,
I'll setup a ve and try them out soon and then add some documentation to both the Arch and Archbang wikis. I'm not preferential on OpenRC for alternative init by any means, but its certainly the most well documented at the moment. I will be testing other init systems as well and adding info on those, in order to fulfill what I see as the Arch philosophy of simplicity while offering choice.
Also, have you or anyone else here managed to get netctl to work without it protesting the lack of systemd? I use netcfg at the moment along with some AUR enhancements for it, but I'd like to maintain as close of a vanilla setup besides my alternate init/udev setup and since it seems netcfg isn't developed officially anymore - I'd like to see if we can correct this.
Offline
Also, have you or anyone else here managed to get netctl to work without it protesting the lack of systemd? I use netcfg at the moment along with some AUR enhancements for it, but I'd like to maintain as close of a vanilla setup besides my alternate init/udev setup and since it seems netcfg isn't developed officially anymore - I'd like to see if we can correct this.
As far as I know, netctl exclusively works only with systemd.
I heard old netcfg works, but I have never used it.
I am gentoo user, who made his secondary arch system gentooish.
I read up on archbang forum, but I can't post there and got restricted read only access.
I was going to answer mrgreen, and to point him to the differences posted here.
MrGreen, eventual conflicts in /etc/conf.d/ can be easily overcome. There are only a few "systemd" packages, which place a file in this dir. Off the top of my head, nfs pkg does that. Renaming the openrc files solves it.
If conflict, my packages append *-rc to the conflicting service files. eg nfs-rc service.
We could think about making the initscript use the arch variables from arch conf file, instead of placing a conf file for initscript.
After reading the thread on archbang, well, without wanting to stir old discussion throughout this thread here, I predicted these troubles with a different $sysconfdir. You should give openrc-base a try.
Installation:
yaourt -S openrc-base
Console system only with network and udev, but no dbus
optional1:
yaourt -S openrc-sys-split
(contains scripts, which would be in base group, lvm, mdadm, devicemapper, dbus, required by optional2 packages)
optional2:
yaourt -S openrc-desktop-split
(desktop scripts, but all individually packaged)
yaourt -S openrc-net-split
(loads of net scripts, but all individually packaged)
yaourt -S openrc-misc-split
(eg. syslog, saned scripts, but all individually packaged)
yaourt -S openrc-devel-split
(db, git & svn scripts, but all individually packaged)
optional:
yaourt -S eudev-openrc
The concept is to have a *-openrc package sit on top of the arch package, eg samba --> samba-openrc, dbus --> dbus-openrc
If you put my packages in a repo, you can do eg:
pacman -S openrc
or
pacman -S openrc-desktop
I'd be so good, if AUR (clients) supported split packages and groups, and the user was able to select individual packages in split build, like makepkg can do with --pkg arg.
Last edited by artoo (2014-04-10 14:26:32)
Offline
Okay Artoo I like your idea and will probably migrate over to your packages, I'm annoyed anyways with apg's packages requiring some DIY. I'll probably do it as soon as Mr Green gets an ArchBang iso for either OpenRC or SysVinit working.
And Gentoo, well lets just say I tried loving it, but it bit me in the arse, so I was like "Screw the bloody thing, I'll just do this with Arch!"
I'll work on trying your packages, but I am due to reOS a server today, so it may have to wait till the weekend.
Offline
artoo, thanks for the packages. I've been running OpenRC for a week now and so far it has saved me the hassle of going back to Gentoo after all these years
Offline
I'd be so good, if AUR (clients) supported split packages and groups, and the user was able to select individual packages in split build, like makepkg can do with --pkg arg.
Next version of AUR code will have (experimental) support for split pacakges. https://mailman.archlinux.org/pipermail … 27837.html
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
artoo wrote:I'd be so good, if AUR (clients) supported split packages and groups, and the user was able to select individual packages in split build, like makepkg can do with --pkg arg.
Next version of AUR code will have (experimental) support for split pacakges. https://mailman.archlinux.org/pipermail … 27837.html
That's great.
I will merge the openrc-sys-split with openrc-base, and have the sys package removed from AUR.
Offline
@artoo: In case I want to give OpenRC and eudev a shot: What is the best way to install it? openrc-base, open-*-split packages and eudev-openrc?
Is the configuration similar to the wiki article (change bootloader line)? I tried the openrc package recently and I had problems with udev and starting gdm...
Offline
@artoo: In case I want to give OpenRC and eudev a shot: What is the best way to install it? openrc-base, open-*-split packages and eudev-openrc?
Is the configuration similar to the wiki article (change bootloader line)? I tried the openrc package recently and I had problems with udev and starting gdm...
Nein, the wiki article is almost exclusively for openrc.
You won't need to change boot parameters. Openrc-base requires plain sysvinit, and thus references /sbin/init, just like systemd does.
To install:
openrc-base & eudev-openrc
You currently need at least openrc-sys-split to get dbus script, if you want to run desktop.
But as announced, openrc-base will have with next release version openrc-sys-split merged. So there won't be a sys-split package very soon.
Unfortunately, I don't have a clue about gdm, I don't use gnome any more since version 3.
I recall from some testing, gdm will have to be compiled with consolekit support, along with couple of other gnome packages.
If you are keen to leave out the sys-split package, you can try the merged build, which will be on AUR soon.
https://github.com/udeved/pkgbuilds/tre … penrc-base
Last edited by artoo (2014-04-17 12:58:16)
Offline
Nein, the wiki article is almost exclusively for openrc.
Sofar it seems all contibutors to the openrc wiki page are users of apg packages.
Wiki content is what WE make of it.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
artoo wrote:Nein, the wiki article is almost exclusively for openrc.
Sofar it seems all contibutors to the openrc wiki page are users of apg packages.
Wiki content is what WE make of it.
Yes, we. I count on shared efforts.
Offline
If I want to start dbus via 'rc-service dbus start' I get the following error:
/usr/bin/dbus-daemon: error while loading shared libraries: libsystemd-login.so.0: cannot open shared object file: No such file or directory
* start-stop-daemon: failed to start '/usr/bin/dbus-daemon'
It has something to do with the removed libsystemd, but when I try to reinstall libsystemd I get another error:
libsystemd and eudev are in conflict. Remove eudev? [y/N]
Offline
If I want to start dbus via 'rc-service dbus start' I get the following error:
/usr/bin/dbus-daemon: error while loading shared libraries: libsystemd-login.so.0: cannot open shared object file: No such file or directory * start-stop-daemon: failed to start '/usr/bin/dbus-daemon'
It has something to do with the removed libsystemd, but when I try to reinstall libsystemd I get another error:
libsystemd and eudev are in conflict. Remove eudev? [y/N]
You'd need dbus-nosystemd from AUR to start dbus running eudev. Also you need upower-nodsystemd and udisks2-nosystemd.
Anyway, there seems to be a problem with eudev(-git) and libsystemd. I just realized in vbox, that its difficult to remove eudev, after libsystemd has become a separate package.
Last edited by artoo (2014-04-18 16:23:48)
Offline
Could somebody else test this eudev build regarding eudev removal?
https://github.com/udeved/pkgbuilds/tre … ev-testing
It works for me, but I would like to make sure before it goes to AUR.
How to make it so, that if systemd is installed again, that libeudev gets removed too?
I think, the only way to achieve it, is to implement it in systemd build.
Last edited by artoo (2014-04-18 20:46:03)
Offline
How to make it so, that if systemd is installed again, that libeudev gets removed too?
I see your libeudev provides libsystemd which is the reason libeudev is not removed on systemd reinstall. Is it necessary to provide libsystemd like that? I mean, isn't it a little dirty to do such a thing unless it is absolutely required.
Last edited by Skry (2014-04-18 22:15:25)
Offline
artoo wrote:How to make it so, that if systemd is installed again, that libeudev gets removed too?
I see your libeudev provides libsystemd which is the reason libeudev is not removed on systemd reinstall. Is it necessary to provide libsystemd like that? I mean, isn't it a little dirty to do such a thing unless it is absolutely required.
Hmpf, I just filed a feature request, to have libsystemd provide=(libudev=$ver).
I guess it is not considered a bug.
https://bugs.archlinux.org/task/39954
I think yes, it is necessary, because eg util-linux depends on libsystemd.
yaourt -S --depends libsystemd
==> Packages which depend on libsystemd:
core/systemd 212-3
core/util-linux 2.24.1-6 (base base-devel) [installed]
extra/gnome-settings-daemon 3.12.1-1 (gnome)
extra/libinput 0.1.0-1
So, any split out eudev library package needs to implement libsystemd interface.
Last edited by artoo (2014-04-18 22:25:56)
Offline
Oh, didn't realize they've gone that far with deps, too bad :\
Offline
Oh, didn't realize they've gone that far with deps, too bad :\
if there was a libudev provides, we would have providers, similar to eg libgl, or ttf providers.
Offline
Falconindy, thank you, I was going to say, it is not only my needs, but the maintainer of eudev-git needs too, or any one who uploads a udev package to AUR.
It just asked, because it can screw up the system, if the correct libraries are not installed.
Offline
artoo,
i noticed you have provides / conflicts AND replaces in the pkgbuild.
the replaces= MIGHT be the cause switching between eudev / libsystemd is so hard.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
artoo,
i noticed you have provides / conflicts AND replaces in the pkgbuild.
the replaces= MIGHT be the cause switching between eudev / libsystemd is so hard.
I have deliberately put them in for testing. It doesn't make a difference.
With the testing build, systemd will flawlessly install, but, it won't remove libeudev by itself, since systemd is happy about libsystemd provided by libeudev.
There is nothing I can do about that in my build. The only option to address this, is putting a libudev or whatever in libsystemd build.
The point is, if someone forgets to manually remove libeudev, the system won't start udev at boot.
It doesn't seem logic to me, that systemd provides udev, but libsystemd won't provide a libudev, as it clearly provides udev libraries along with systemd libs.
Last edited by artoo (2014-04-19 14:46:20)
Offline
Lone_Wolf wrote:artoo,
i noticed you have provides / conflicts AND replaces in the pkgbuild.
the replaces= MIGHT be the cause switching between eudev / libsystemd is so hard.I have deliberately put them in for testing. It doesn't make a difference.
With the testing build, systemd will flawlessly install, but, it won't remove libeudev by itself, since systemd is happy about libsystemd provided by libeudev.
There is nothing I can do about that in my build. The only option to address this, is putting a libudev or whatever in libsystemd build.
The point is, if someone forgets to manually remove libeudev, the system won't start udev at boot.It doesn't seem logic to me, that systemd provides udev, but libsystemd won't provide a libudev.
None of your packages should include replaces=. If you add systemd as a conflict for libeudev pacman should take care of the replacement.
Offline