OpenRC & eudev on Arch

artoo · 2014-04-19 14:48:01

apg wrote:

artoo wrote:
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.

It should, if libsystemd conflicted with a theoretical libudev, as systemd does with udev.

As said, the replaces are not originally in, rather than deliberate attempt to solve the problem.

PS: I can offer to make screenshot with a tweaked libsystemd, and with repo libsystemd.
Tweaked libsystemd will remove libeudev, repo libsystemd won't.

Last edited by artoo (2014-04-19 14:59:21)

apg · 2014-04-19 15:08:47

artoo wrote:

apg wrote:
None of your packages should include replaces=. If you add systemd as a conflict for libeudev pacman should take care of the replacement.
It should, if libsystemd conflicted with a theoretical libudev, as systemd does with udev.
As said, the replaces are not originally in, rather than deliberate attempt to solve the problem.
PS: I can offer to make screenshot with a tweaked libsystemd, and with repo libsystemd.
Tweaked libsystemd will remove libeudev, repo libsystemd won't.

If you add conflicts=(systemd) to libeudev, pacman should remove libeudev and replace it with libsystemd when you replace eudev with systemd. If it doesn't, that's a bug.

artoo · 2014-04-19 15:13:09

apg wrote:

artoo wrote:
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.

I say it again, the replaces was a deliberate attempt to solve this.
I am aware of the guidelines concerning replaces.

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

Anyway, that's my reasoning, I consider it a bug by now. But if I filed a bug report instead of feature request, it would likely have gone the same way. "Won't implement. Closed"

The real trouble is eg util-linux depending on libsystemd, instead of libudev, which is afaik all it needs. Any separate udev package could happily drop the systemd provides.

Last edited by artoo (2014-04-19 15:24:23)

apg · 2014-04-19 15:29:05

apg wrote:

If you add conflicts=(systemd) to libeudev, pacman should remove libeudev and replace it with libsystemd when you replace eudev with systemd. If it doesn't, that's a bug.

artoo wrote:

I say it again, the replaces was a deliberate attempt to solve this.
I am aware of the guidelines concerning replaces.
Anyway, that's my reasoning, it consider it a bug by now. But if I filed a bug report instead of feature request, it would likely have gone the same way. "Won't implement. Closed"
The real trouble is eg util-linux depending on libsystemd, instead of libudev, which is afaik all it needs. Any separate udev package could happily drop the systemd provides.

Regardless of what any repo packages provide, conflict, replace, or require, if your specific problem is that replacing eudev with systemd doesn't also replace libeudev with libsystemd, adding conflicts=systemd to libeudev should allow pacman to handle the replacement. If it does not, that is a bug in pacman.

Last edited by apg (2014-04-19 15:34:42)

ewaller · 2014-04-19 15:37:48

man pacman wrote:

BUGS
Bugs? You must be kidding, there are no bugs in this
software. But if we happen to be wrong, send us an email
with as much detail as possible to
pacman-dev@archlinux.org.

artoo · 2014-04-19 15:42:28

apg wrote:

apg wrote:
If you add conflicts=(systemd) to libeudev, pacman should remove libeudev and replace it with libsystemd when you replace eudev with systemd. If it doesn't, that's a bug.
artoo wrote:
I say it again, the replaces was a deliberate attempt to solve this.
I am aware of the guidelines concerning replaces.
Anyway, that's my reasoning, it consider it a bug by now. But if I filed a bug report instead of feature request, it would likely have gone the same way. "Won't implement. Closed"
The real trouble is eg util-linux depending on libsystemd, instead of libudev, which is afaik all it needs. Any separate udev package could happily drop the systemd provides.
Regardless of what any repo packages provide, conflict, replace, or require, if your specific problem is that replacing eudev with systemd doesn't also replace libeudev with libsystemd, adding conflicts=systemd to libeudev should allow pacman to handle the replacement. If it does not, that is a bug in pacman.

Try it. We can then talk about what you encountered, and I encountered yesterday.

apg · 2014-04-19 17:16:52

artoo wrote:

apg wrote:
Regardless of what any repo packages provide, conflict, replace, or require, if your specific problem is that replacing eudev with systemd doesn't also replace libeudev with libsystemd, adding conflicts=systemd to libeudev should allow pacman to handle the replacement. If it does not, that is a bug in pacman.
Try it. We can then talk about what you encountered, and I encountered yesterday.

Hrmm, I would have sworn pacman could replace dependencies it removed due to conflicts... I would suggest just adding a post-remove message to the eudev package telling users to replace libeudev as well.

artoo · 2014-04-19 17:45:37

apg wrote:

artoo wrote:
apg wrote:
Regardless of what any repo packages provide, conflict, replace, or require, if your specific problem is that replacing eudev with systemd doesn't also replace libeudev with libsystemd, adding conflicts=systemd to libeudev should allow pacman to handle the replacement. If it does not, that is a bug in pacman.
Try it. We can then talk about what you encountered, and I encountered yesterday.
Hrmm, I would have sworn pacman could replace dependencies it removed due to conflicts... I would suggest just adding a post-remove message to the eudev package telling users to replace libeudev as well.

Yes, indeed.

But its not a pacman bug, but a packaging issue.

If there was a libudev in libsystemd, I could rename libeudev in libudev, and all would be fine.

F34R · 2014-05-06 08:35:16

latest try with openrc and singe eudev my system corrupted and i return to systemd.
In aur repo available different packages, what install for my system ?

eudev-openrc
openrc 0.12.4-1 (single packages)
openrc-base (udev enabled)
openrc-sysvinit

and eudev packages:

eudev 1.6.-1
eudev-openrc (eudev postmount script)

what is the correct method now ?

Last edited by F34R (2014-05-06 08:35:42)

artoo · 2014-05-07 13:30:04

What version corrupted your system?
openrc(-git) or openrc-base?

If it was openrc(-git), you would have to talk to apg.

Sorry for confusion, but apg and me couldn't agree on some points, thus, we got two incompatible openrc versions in AUR.

If you use openrc-base, then its me you would ask for help. If its openrc(-git), its apg.

A 'yaourt -S openrc-base' && yaourt -S eudev-openrc' should do to get you a basic openrc system installed.

Don't use packer for AUR, it can't deal with split packages very good.
Contrary to yaourt, packer will only install openrc-base, but its a split package, and it won't install the dbus-openrc pkg.

At best, you use makepkg instead of AUR client programm.

Lone_Wolf · 2014-05-07 14:13:36

F34R,

Apg pacakges openrc & openrc-git afaik have only been tested against udev from systemd.

If you want to use eudev, artoo packages are the only choice .

eNTi · 2014-05-16 20:57:47

you guys are great. i'm so happy i can drop systemd for openrc.

there are missing quite some init scripts... can anyone tell me where to get ... for example the init script for nfs (rpcbind)? kind a bit confused because just running "rpcbind start" is all that is needed for me to actually be able to mount nfs volumes.

i also found that i couldn't start my kernel WITHOUT openrc any longer after installing everything suggested on the wiki page... is that supposed to happen?

Last edited by eNTi (2014-05-16 20:59:04)

artoo · 2014-05-17 08:25:07

eNTi wrote:

you guys are great. i'm so happy i can drop systemd for openrc.
there are missing quite some init scripts... can anyone tell me where to get ... for example the init script for nfs (rpcbind)? kind a bit confused because just running "rpcbind start" is all that is needed for me to actually be able to mount nfs volumes.
i also found that i couldn't start my kernel WITHOUT openrc any longer after installing everything suggested on the wiki page... is that supposed to happen?

You need to ask apg. You seem to use his version.
I won't do support for his packages.

rpcbind is in openrc-net, which is incompatible with apg openrc(-git) versions. Pacman won't allow you to install it, it conflicts with these versions.

I am getting a bit tired of stating same thing over and over again.

Last edited by artoo (2014-05-17 08:30:05)

Lone_Wolf · 2014-05-17 12:38:02

@artoo :
i do feel it would make things easier if posters in this thread would clarify which openrc packages they use : yours or apg when asking for help.
Whether we like it or not, this thread is used by all users of openrc on archlinux, regardless of which set of packages they use.

I have found in the past that using your services with apg packages is doable with some manual changes, although they do have way to much stuff in them that's needed to work on gentoo but unnecesary for arch.

@enTI :
basic services are included in apg openrc-arch-services-git package.
some users have forked his repo and may have additional services, https://github.com/andrewgregory/openrc … es/network .

X33a has his own separate repo and tends to have the most additional services in it : https://github.com/notfoss/archlinux-openrc-services
All of those were created by apg or the users of his packages because they needed certain services.
You might be the first one of us who wants an nfs service.

booting systemd instead of apg openrc :
It should work, but you'll have to create a separate boot entry in your boot loader .
you will have to specify the path to systemd's init for it to work.
In my syslinux.cfg i have this to boot systemd :

LABEL arch1
	MENU LABEL Arch - systemd
	LINUX ../vmlinuz-linux
	APPEND root=/dev/sda2 rw init=/usr/lib/systemd/systemd
	INITRD ../initramfs-linux.img

artoo · 2014-05-17 14:46:09

I would agree, stating openrc version is good idea.

Best solution would be, if the wiki mentioned the other verion.
Could safe lots of redundant posting.

I just raised my points early in the thread, I don't see why I should do support for a version, I raised my points about. Its not my construction site, is it?
My version doesn't need some kernel parameter to boot, no matter systemd or openrc, whereas apg's does need the param.

I mean, apg is maintainer, hence he should do some support. Seems fair to me.

Last edited by artoo (2014-05-17 14:55:13)

Lone_Wolf · 2014-05-18 13:31:02

artoo wrote:

I would agree, stating openrc version is good idea.
Best solution would be, if the wiki mentioned the other verion.
Could safe lots of redundant posting.

frankly, I've been waiting for some time for an artoo packages user (i don't mean artoo) to add to the wiki, but it seems that's not going to happen.
I think i have a reasonable understanding of the differences between apg and artoo packages, so i'll look into editing the wiki page this week.

artoo · 2014-05-19 10:00:19

Lone_Wolf wrote:

artoo wrote:
I would agree, stating openrc version is good idea.
Best solution would be, if the wiki mentioned the other verion.
Could safe lots of redundant posting.
frankly, I've been waiting for some time for an artoo packages user (i don't mean artoo) to add to the wiki, but it seems that's not going to happen.
I think i have a reasonable understanding of the differences between apg and artoo packages, so i'll look into editing the wiki page this week.

Me too, but maybe a wiki entry get it starting? Who knows.
Would be very kind of you to do.

What stuff isn't necessarily needed in my script packages? They match the runscript depends.

Remember, I use netifrc for network, not (it seems atm) unmaintained "newnet".
The networking is main difference besides my default sysconfdir and udev default.
Help for network is referenced in the install file of my openrc-base build.
It provides a link to gentoo networkguide.
Oh, and openrc-base has become a split pkg, which also provides the runscripts of packges in arch base group.

NM users will probably experience with apg version that NM doesn't properly update status, showing something like "waiting".
The arch NM doesn't have a openrc specific library provided.

Services can also be handled without path

# rc-service xyz {start,stop,restart,status}

My version conflicts with initscripts, so no two similar rc init systems can be installed, The user has to make a choice.
However, as long as systemd remains installed as mere udev provider, systemd can be started by adding kernel param.
But installing openrc does not need a modified bootloader config. It uses sysvinit, and uses /usr/bin/init

Btw, do you eventually know if the mkaur tool is somewhere available, the thingy for split pkg support? Or is it in pacman's makepkg already?

Last edited by artoo (2014-05-19 11:12:27)

lechindianer · 2014-05-20 07:22:23

Could you please update the ArchLinux wiki article on OpenRC? It's confusing for all OpenRC beginners to have 2 incompatible packages.

Lone_Wolf · 2014-05-28 13:31:31

artoo wrote:

Btw, do you eventually know if the mkaur tool is somewhere available, the thingy for split pkg support? Or is it in pacman's makepkg already?

it's now in [community] in the pkgbuild-introspection package.
https://mailman.archlinux.org/pipermail … 28539.html

Changing the openrc wiki page is proving much harder then i expected (every draft i made sofar shows my bias towards apg packages way to much).
I'll keep trying though.

aaditya · 2014-06-02 16:19:55

I split the method for installation in the Wiki into 2 ways: apg way and artoo way; apg way as is and for artoo's way I simply used artoo's reply #355.

For configuration, I added that apg's method uses /etc/openrc/* and artoo's use /etc/*

Probably not much, but anyone is free to edit..

Disclaimer: I am not well versed with openrc, but trying it out to see if I can replace systemd.

x33a · 2014-06-02 17:44:12

@ aaditya, that's a good start. Thanks for the effort.

aaditya · 2014-06-02 18:39:41

x33a wrote:

@ aaditya, that's a good start. Thanks for the effort.

No problem x33a You started it
I will try add more as I can.

aaditya · 2014-06-03 06:04:23

Some points corrected and more stuff added in the OpenRC wiki page.

aaditya · 2014-06-07 04:56:11

Hey guys,

I wrote a blog describing my experiences on setting up OpenRC.
http://abchk1234.wordpress.com/2014/06/ … aro-linux/

x33a · 2014-06-07 07:01:39

@ aaditya, artoo should finally be happy now

Arch Linux

#326 2014-04-19 14:48:01

Re: OpenRC & eudev on Arch

#327 2014-04-19 15:08:47

Re: OpenRC & eudev on Arch

#328 2014-04-19 15:13:09

Re: OpenRC & eudev on Arch

#329 2014-04-19 15:29:05

Re: OpenRC & eudev on Arch

#330 2014-04-19 15:37:48

Re: OpenRC & eudev on Arch

#331 2014-04-19 15:42:28

Re: OpenRC & eudev on Arch

#332 2014-04-19 17:16:52

Re: OpenRC & eudev on Arch

#333 2014-04-19 17:45:37

Re: OpenRC & eudev on Arch

#334 2014-05-06 08:35:16

Re: OpenRC & eudev on Arch

#335 2014-05-07 13:30:04

Re: OpenRC & eudev on Arch

#336 2014-05-07 14:13:36

Re: OpenRC & eudev on Arch

#337 2014-05-16 20:57:47

Re: OpenRC & eudev on Arch

#338 2014-05-17 08:25:07

Re: OpenRC & eudev on Arch

#339 2014-05-17 12:38:02

Re: OpenRC & eudev on Arch

#340 2014-05-17 14:46:09

Re: OpenRC & eudev on Arch

#341 2014-05-18 13:31:02

Re: OpenRC & eudev on Arch

#342 2014-05-19 10:00:19

Re: OpenRC & eudev on Arch

#343 2014-05-20 07:22:23

Re: OpenRC & eudev on Arch

#344 2014-05-28 13:31:31

Re: OpenRC & eudev on Arch

#345 2014-06-02 16:19:55

Re: OpenRC & eudev on Arch

#346 2014-06-02 17:44:12

Re: OpenRC & eudev on Arch

#347 2014-06-02 18:39:41

Re: OpenRC & eudev on Arch

#348 2014-06-03 06:04:23

Re: OpenRC & eudev on Arch

#349 2014-06-07 04:56:11

Re: OpenRC & eudev on Arch

#350 2014-06-07 07:01:39

Re: OpenRC & eudev on Arch

Board footer