OpenRC & eudev on Arch

Mr Green · 2012-11-22 18:17:50

base is a meta package [pacman -Qqg base] so is not reallt art of abs

artoo can you add a link in your signature to your repo....

Last edited by Mr Green (2012-11-22 18:19:19)

artoo · 2012-11-22 19:41:11

Mr Green wrote:

base is a meta package [pacman -Qqg base] so is not reallt art of abs
artoo can you add a link in your signature to your repo....

Yes, but this meta pkg must be somewhere defined in one of the core pkgbuilds.

Signature done.

Last edited by artoo (2012-11-22 19:41:35)

Barthalion · 2012-11-22 20:08:08

This is why I trust apg more than artoo…

smil3y · 2012-11-22 20:09:29

artoo wrote:

Mr Green wrote:
base is a meta package [pacman -Qqg base] so is not reallt art of abs
artoo can you add a link in your signature to your repo....

Yes, but this meta pkg must be somewhere defined in one of the core pkgbuilds.
Signature done.

Those are groups, take a look at https://www.archlinux.org/packages/core/i686/coreutils/ and you will see it's in the base group.

artoo · 2012-11-22 20:25:28

Barthalion wrote:

This is why I trust apg more than artoo…

Maybe the TU has a constructive answer to the question?

How to set default select value for meta packages?

smil3y · 2012-11-22 20:32:42

artoo wrote:

How to set default select value for meta packages?

Use

groups=('group1' 'group2')

I guess you haven't looked at the PKGBUILD of coreutils after all. At least check this out https://wiki.archlinux.org/index.php/PKGBUILD from top to bottom.

Last edited by smil3y (2012-11-22 20:32:56)

artoo · 2012-11-22 21:17:40

smil3y wrote:

artoo wrote:
How to set default select value for meta packages?
Use
groups=('group1' 'group2')
I guess you haven't looked at the PKGBUILD of coreutils after all. At least check this out https://wiki.archlinux.org/index.php/PKGBUILD from top to bottom.

Nono, I have read there.
I already have meta packages, the question is as follows:

I have eg openrc4arch-meta-syslog providing two syslog possibilities, rsyslog(1) & syslog-ng(2) .
Now, the meta package somehow sets rsyslog as default choice(1)

How to set to syslog-ng (2)?

Is there a way to set eg like with base package an 'all' select option?
With a group?

Thanks, coreutils, that seems to be the package build I was asking for.

Last edited by artoo (2012-11-22 21:22:39)

karol · 2012-11-22 21:50:36

'base' is not a virtual package, it's a package group.
What exactly are you trying to do? 'base' is expected to be installed. If some packages from 'base' group are not present, it's considered to be user's problem, not a packaging bug.

Please disregard, I missed that there's a second page to this thread now.

Last edited by karol (2012-11-22 21:52:28)

Lone_Wolf · 2012-11-22 22:46:59

Artoo, some questions :

- while most of the pacakges are of 'any' type, openrc4arch and consolekit are x86_64 only.
Will there be i686 versions of those ?
If not, you should add a note to the arch4openrc webpage.

- I can't find the PKGBUILDS for your packages, do you intend to make those available ?

- why do you use openrc4arch-*-plugin instead of something like openrc4arch-service-* ?

- your openrc4arch-*-plugin packages install in /etc/init.d .
This directory is normally not present on archlinux, but has a certain meaning for other distros i think.

initscripts used rc.d, systemd config and service files are under etc/systemd .
apg choose /etc/.openrc for service files in his openrc packages.

If you were to use something like /etc/openrc4arch , it would be cleaner and imo closer to arch packaging standards.

artoo · 2012-11-22 23:14:56

First, the 'groups' seem to do the job for the 'all' option.

But, I figured, the default value seems to depend on alphabetic order.

To make it clear, I want to control this value:

Lone_Wolf wrote:

Artoo, some questions :
- while most of the pacakges are of 'any' type, openrc4arch and consolekit are x86_64 only.
Will there be i686 versions of those ?
If not, you should add a note to the arch4openrc webpage.
- I can't find the PKGBUILDS for your packages, do you intend to make those available ?
- why do you use openrc4arch-*-plugin instead of something like openrc4arch-service-* ?
- your openrc4arch-*-plugin packages install in /etc/init.d .
This directory is normally not present on archlinux, but has a certain meaning for other distros i think.
initscripts used rc.d, systemd config and service files are under etc/systemd .
apg choose /etc/.openrc for service files in his openrc packages.
If you were to use something like /etc/openrc4arch , it would be cleaner and imo closer to arch packaging standards.

I probably will do i686 packages later on, since I need to test first on i686 if the openrc4arch package runs on i686 with "any" build config. I am currently not sure about that. If it runs, which I doubtbecause of the rc binary, then all pkgs would be 'any' arch.

Pkgbuild are already available here, or the link near the email entry.

The data git repo for the plugins:
https://github.com/udeved/openrc-data

The pkgbuilds:
https://github.com/udeved/openrc-pkgbuilds

Concerning a separate directory for openrc in /etc, this is apq's approach.
Well, after looking at openrc sources, I think messing with that causes more trouble than good, since some paths in openrc source are hardcoded. It would increase maintenance for openrc source to run properly on Arch in my view.
Hence, I made unaltered packages, vanilla so to speak.
Only a consolefont path patch is necessary atm, and this will likely remain a constant.

Additionally, /etc/init.d and /etc/conf.d are pretty standard dirs, Arch still uses the /etc/conf.d/ dir for some packages. The files in /etc/conf.d on Arch and the openrc /etc/conf.d files are almost the same.
The latest changes I made use the Arch provided files in /etc/conf.d/

apg · 2012-11-23 01:37:09

I have already submitted patches upstream for all of the problematic paths you have identified. Although the original paths haven't caused any issues for me, anybody that does encounter issues can try the patched version by building from the working branch of my github repo at https://github.com/andrewgregory/openrc

Lone_Wolf · 2012-11-23 12:00:39

artoo wrote:

Lone_Wolf wrote:
Artoo, some questions :
- while most of the pacakges are of 'any' type, openrc4arch and consolekit are x86_64 only.
Will there be i686 versions of those ?
If not, you should add a note to the arch4openrc webpage.
- I can't find the PKGBUILDS for your packages, do you intend to make those available ?
- why do you use openrc4arch-*-plugin instead of something like openrc4arch-service-* ?
- your openrc4arch-*-plugin packages install in /etc/init.d .
This directory is normally not present on archlinux, but has a certain meaning for other distros i think.
initscripts used rc.d, systemd config and service files are under etc/systemd .
apg choose /etc/.openrc for service files in his openrc packages.
If you were to use something like /etc/openrc4arch , it would be cleaner and imo closer to arch packaging standards.

I probably will do i686 packages later on, since I need to test first on i686 if the openrc4arch package runs on i686 with "any" build config. I am currently not sure about that. If it runs, which I doubtbecause of the rc binary, then all pkgs would be 'any' arch.

Check the lay-out for arch offical repos, you'll see that they have separate x86_64 and i686 folders .

artoo wrote:

Pkgbuild are already available here, or the link near the email entry.
The data git repo for the plugins:
https://github.com/udeved/openrc-data
The pkgbuilds:
https://github.com/udeved/openrc-pkgbuilds

Put those links on the page in your sig then, so all info is availabe from 1 place ?

artoo wrote:

Concerning a separate directory for openrc in /etc, this is apq's approach.
Well, after looking at openrc sources, I think messing with that causes more trouble than good, since some paths in openrc source are hardcoded. It would increase maintenance for openrc source to run properly on Arch in my view.
Hence, I made unaltered packages, vanilla so to speak.
Only a consolefont path patch is necessary atm, and this will likely remain a constant.Additionally, /etc/init.d and /etc/conf.d are pretty standard dirs, Arch still uses the /etc/conf.d/ dir for some packages. The files in /etc/conf.d on Arch and the openrc /etc/conf.d files are almost the same.
The latest changes I made use the Arch provided files in /etc/conf.d/

Atm your packages don't comply with arch packaging standards, check the wiki.
https://wiki.archlinux.org/index.php/Ar … irectories describes how to deal with /etc and configuration files (among other things).
Also check the arch VCS guidelines, all git packages should be named something-git .

I agree with apg that submitting patches upstream is the best solution for path conflicts.

Last edited by Lone_Wolf (2012-11-23 12:02:03)

artoo · 2012-11-23 13:59:51

Lone_Wolf wrote:

Atm your packages don't comply with arch packaging standards, check the wiki.
https://wiki.archlinux.org/index.php/Ar … irectories describes how to deal with /etc and configuration files (among other things).
Also check the arch VCS guidelines, all git packages should be named something-git .
I agree with apg that submitting patches upstream is the best solution for path conflicts.

Are you a bureaucrat?

Concerning package standards.
Where would you implement /libexec?
Apq's build also uses /libexec.

I tried in /usr/lib and openrc fails.
On gentoo you have a /lib on the root partition, on Arch not anymore, just symlink.
I am also not too happy with the /libexec dir.

The plugins are not directly git, in the sense that they only provide usually one script file which won't change much. They are replacements for removed /etc/rc.d/* scripts due to systemd switch.

I have been thinking about version numbering parallel to gentoo.
eg. openrc is currently v 0.12, hence the names for the packages and their versions are not final.
As for the name plugin instead of service, I think plugin describes it, The services are installed by the corresponding package. the openrc plugin just provides the run script to start/stop/restart the service.

Feel free to submit upstream patches for OpenRC. I won't.
I won't spend time on gentoo's openrc dev asking for specific non gentoo, non standard paths.

Anyway, nobody forces you to use non Arch standard packages.

I don't see a problem with the init.d directory. Every distribution has one or an equivalent dir, placing the dir in yet another dir still makes the init.d dir foreign to Arch, this includes funnily the proposed openrc dir too.
I find it more clean to place the directories where they are intended to be placed.

Last edited by artoo (2012-11-23 21:48:07)

Mr Green · 2012-11-23 14:49:34

Have not got automounting working yet, dbus udev are of course running enabled hotplug in rc.conf but in pcmanfm I can see device but I do not have permission to mount it. Not that a simply sudo mount /dev<device> <mountpoint> cannot do the job just as easily. At the moment I am using networkmanager but nm-applet does not seems to work.

Last edited by Mr Green (2012-11-23 14:49:56)

artoo · 2012-11-23 18:36:07

Mr Green wrote:

Have not got automounting working yet, dbus udev are of course running enabled hotplug in rc.conf but in pcmanfm I can see device but I do not have permission to mount it. Not that a simply sudo mount /dev<device> <mountpoint> cannot do the job just as easily. At the moment I am using networkmanager but nm-applet does not seems to work.

A guess in the blue.
Have you installed polit-consolekit package from AUR?
https://aur.archlinux.org/packages/polkit-consolekit/

Official Arch polkit package has systemd support, probably the reason authorization doesn't work on your box.

I have the polkit-consolekit installed with kde on my productive box, and the mounting and authorization works here.

Make sure you add dbus and consolekit to default runlevel. I guess you already did that.

Edit:

Networkmanager also works in combination with this AUR package:
https://aur.archlinux.org/packages/netw … onsolekit/

Last edited by artoo (2012-11-23 18:40:51)

Mr Green · 2012-11-23 20:23:58

I have dbus added [rc-update add dbus] but will try the polkit-consolekit... thanks

Lone_Wolf · 2012-11-23 22:32:36

artoo wrote:

<snip>
Concerning package standards.
Where would you implement /libexec?
Apq's build also uses /libexec.
I tried in /usr/lib and openrc fails.
On gentoo you have a /lib on the root partition, on Arch not anymore, just symlink.
I am also not too happy with the /libexec dir.
<snip>
Feel free to submit upstream patches for OpenRC. I won't.
I won't spend time on gentoo's openrc dev asking for specific non gentoo, non standard paths.
Anyway, nobody forces you to use non Arch standard packages.
I don't see a problem with the init.d directory. Every distribution has one or an equivalent dir, placing the dir in yet another dir still makes the init.d dir foreign to Arch, this includes funnily the proposed openrc dir too.
I find it more clean to place the directories where they are intended to be placed.

haven't looked into /libexec yet, but agree it seems weird and is likely against arch standards.

according to gentoo wiki on openrc, openrc is not gentoo-exclusive .
That suggests the openrc developers will accept patches to make openrc work better on non-gentoo sytems.

You are right, nobody forces me to use non arch standard packages.
I feel arch packaging standards are 1 of the things that make arch a better distro.
The fact you don't want to comply with them, reduces the chances i'll be using your repo a lot.

In earlier posts you stated you would not be maintaining the packages you submitted to the aur anymore.
If you mean that, i suggest you orphan them or even ask on the aur-general mailing list for their removal.
unmaintained packages in aur are a bad thing.

artoo · 2012-11-23 23:33:33

Lone_Wolf wrote:

artoo wrote:
<snip>
Concerning package standards.
Where would you implement /libexec?
Apq's build also uses /libexec.
I tried in /usr/lib and openrc fails.
On gentoo you have a /lib on the root partition, on Arch not anymore, just symlink.
I am also not too happy with the /libexec dir.
<snip>
Feel free to submit upstream patches for OpenRC. I won't.
I won't spend time on gentoo's openrc dev asking for specific non gentoo, non standard paths.
Anyway, nobody forces you to use non Arch standard packages.
I don't see a problem with the init.d directory. Every distribution has one or an equivalent dir, placing the dir in yet another dir still makes the init.d dir foreign to Arch, this includes funnily the proposed openrc dir too.
I find it more clean to place the directories where they are intended to be placed.
haven't looked into /libexec yet, but agree it seems weird and is likely against arch standards.
according to gentoo wiki on openrc, openrc is not gentoo-exclusive .
That suggests the openrc developers will accept patches to make openrc work better on non-gentoo sytems.
You are right, nobody forces me to use non arch standard packages.
I feel arch packaging standards are 1 of the things that make arch a better distro.
The fact you don't want to comply with them, reduces the chances i'll be using your repo a lot.
In earlier posts you stated you would not be maintaining the packages you submitted to the aur anymore.
If you mean that, i suggest you orphan them or even ask on the aur-general mailing list for their removal.
unmaintained packages in aur are a bad thing.

Well, I don't quite get your beef with standards.

There is no arch standard which says, "put your config files in a sub-sub-directory of /etc". At least I am not aware of it. Point me to it please.

As mentioned, /libexec dir is rather a forced choice to make, due to the lack of a true /lib dir on the root partition on Arch. Gentoo have not moved fully to /usr yet, and probably won't do it fully. So, no upstream patch for openrc will fix this problem until gentoo moved eventually to /usr.

I could place it in /usr/lib, but what about users with separate /usr partition? I am one of them.

Of course I will try to comply with certain package standards, but this is atm not my main goal, and actually the packages are not in any official repo. So I don't see a problem there, really.

I f you want to have init.d and conf.d in a subdirectory of /etc, such as /etc/openrc, simply use apq's builds or change my ones to point to /etc/openrc.

I really don't get why people would want to have a non standard path in /etc. Boxed directories are not my thing, if not necessary. My view on /etc/openrc path, it is unnecessary, complicating the port, and giving gentoo devs an unnecessary task to comply with foreign distro 'demands'. I guess they also have other priorities than changing some pretty standard path to a more dynamic approach.
It runs fine as it is, why put a stone in the way which only complicates it?

The /etc dir is apparently intended for configuration. By making it into a subdir maybe complies with some Arch standards, but it doesn't really comply with general linux standards to put config dirs in /etc.

What bothers you so much about /etc/init.d? OpenRC is the only package which makes use of it on Arch. And as previously said, /etc/conf.d already exists on Arch. Why introduce yet another subdir to place very similar files in a new dir which are already present? I thought we seek a clean solution? Having two almost identical directories is not a clean approach in my opinion.

I am providing the packages just for fun and the sake of sharing. It may make people happy who look for systemd alternative. Nobody forces me to provide them, nor others to use them.

Yes, I will mark the AUR packages obsolete. Good call there.

Last edited by artoo (2012-11-24 00:06:29)

Allan · 2012-11-24 00:17:05

artoo wrote:

As mentioned, /libexec dir is rather a forced choice to make, due to the lack of a true /lib dir on the root partition on Arch. Gentoo have not moved fully to /usr yet, and probably won't do it fully. So, no upstream patch for openrc will fix this problem until gentoo moved eventually to /usr.
I could place it in /usr/lib, but what about users with separate /usr partition? I am one of them.

We will be moving /bin and /sbin into /usr much like /lib soon, so it would be a good idea to get this sorted sooner...

artoo · 2012-11-24 00:27:17

Allan wrote:

artoo wrote:
As mentioned, /libexec dir is rather a forced choice to make, due to the lack of a true /lib dir on the root partition on Arch. Gentoo have not moved fully to /usr yet, and probably won't do it fully. So, no upstream patch for openrc will fix this problem until gentoo moved eventually to /usr.
I could place it in /usr/lib, but what about users with separate /usr partition? I am one of them.
We will be moving /bin and /sbin into /usr much like /lib soon, so it would be a good idea to get this sorted sooner...

Interesting info, thanks.

This could eventually break openrc on Arch, and it would leave a gap until gentoo did something similar.

It'd be quite a lot of work to adapt current openrc sources to the /usr partition. Hmm.

apg · 2012-11-24 01:06:01

artoo wrote:

My view on /etc/openrc path, it is unnecessary, complicating the port, and giving gentoo devs an unnecessary task to comply with foreign distro 'demands'. I guess they also have other priorities than changing some pretty standard path to a more dynamic approach.

This whole "burdening the devs" argument is just silly. If you write and submit the patch, their "burden" consists of running `git am`. Furthermore, OpenRC is designed to allow these customizations and anytime they don't work is a bug. By fixing these bugs you do the devs a favor by making the software more robust.

artoo wrote:

I really don't get why people would want to have a non standard path in /etc. Boxed directories are not my thing, if not necessary. ... It runs fine as it is, why put a stone in the way which only complicates it?

As to the '/etc/openrc' directory, as I have pointed out, putting conf.d directly in /etc will conflict with the packages that include an initscript file that uses a configuration file in /etc/conf.d, leaving you with two options that I can see if you don't use a subdirectory:

make sure that your service files are compatible with the conf.d files provided by all of those packages and just leave the conf files out of your own package then add them in individually as they are removed from the official packages
give all of your service files names different from those provided by the packages (/etc/{init.d,conf.d}/openrc_dhcpcd, /etc/{init.d,conf.d}/openrc_acpid, etc...).

You don't appear to be doing either of those things so several of your packages conflict with the very packages they're supposed to work with (rsyslog for example).

Lone_Wolf wrote:

haven't looked into /libexec yet, but agree it seems weird and is likely against arch standards.

When it comes to /libexec OpenRC is a bit unconventional. It not only uses it to store executables but also for a cache and temporary files, so it doesn't really fit properly anywhere as is. Moving it to /usr/lib/openrc also had the unfortunate effect of breaking openrc for me (no, I do not have /usr on a separate partition). For the time being I will be leaving it as /libexec in my own packages, when I have more time again I will revisit the possibility of moving it somewhere more conventional.

slowpoke · 2012-11-28 06:24:51

Ahoy,

just wanted to chime in and thank the people here for the work done already. I'm running OpenRC with a Linux-ck kernel and it works absolutely fine. I'll read the entire thread later and see if I can help in any way.

artoo · 2012-11-29 14:50:31

Update 1.12.2012:

I have changed the install path to /usr/lib/rc and it runs with sep. /usr too.

I have also changed the binary paths, now pointing to /usr/bin and /usr/sbin respectively.

Edit:
The repo structure has changed, I spilt it into three, stable(old repo updated), testing and unstable.

See http://www.openrc4arch.site40.net/index.php?news&nid=3

The openrc4arch-git package in the testing repo installs to /usr, and is ready for arch /usr/bin and /usr/sbin move.
The openrc4arch-git package has the old network enabled, as long as the new network does not work properly on Linux. (See OpenRC readme and feature removal)

I would recommend to clean previous openrc4arch install and delete the /libexec directory on the root partition.

Last edited by artoo (2012-12-01 20:30:19)

calc · 2012-11-30 06:12:16

yes

Last edited by calc (2014-03-08 13:36:28)

artoo · 2012-12-01 20:29:59

Current plugin packages feature groups.
Following group installs are available:

openrc4arch-cron
openrc4arch-db
openrc4arch-desktop
openrc4arch-fs
openrc4arch-mobile
openrc4arch-net
openrc4arch-print
openrc4arch-syslog
openrc4arch-vbox
openrc4arch-vcs
openrc4arch-www

Repos:

[openrc4arch]
SigLevel = Never
Server = http://www.openrc4arch.site40.net/$repo/os/$arch

[openrc4arch-testing]
SigLevel = Never
Server = http://www.openrc4arch.site40.net/$repo/os/$arch

[openrc4arch-unstable]
SigLevel = Never
Server = http://www.openrc4arch.site40.net/$repo/os/$arch

Last edited by artoo (2012-12-03 13:49:56)

Arch Linux

#76 2012-11-22 18:17:50

Re: OpenRC & eudev on Arch

#77 2012-11-22 19:41:11

Re: OpenRC & eudev on Arch

#78 2012-11-22 20:08:08

Re: OpenRC & eudev on Arch

#79 2012-11-22 20:09:29

Re: OpenRC & eudev on Arch

#80 2012-11-22 20:25:28

Re: OpenRC & eudev on Arch

#81 2012-11-22 20:32:42

Re: OpenRC & eudev on Arch

#82 2012-11-22 21:17:40

Re: OpenRC & eudev on Arch

#83 2012-11-22 21:50:36

Re: OpenRC & eudev on Arch

#84 2012-11-22 22:46:59

Re: OpenRC & eudev on Arch

#85 2012-11-22 23:14:56

Re: OpenRC & eudev on Arch

#86 2012-11-23 01:37:09

Re: OpenRC & eudev on Arch

#87 2012-11-23 12:00:39

Re: OpenRC & eudev on Arch

#88 2012-11-23 13:59:51

Re: OpenRC & eudev on Arch

#89 2012-11-23 14:49:34

Re: OpenRC & eudev on Arch

#90 2012-11-23 18:36:07

Re: OpenRC & eudev on Arch

#91 2012-11-23 20:23:58

Re: OpenRC & eudev on Arch

#92 2012-11-23 22:32:36

Re: OpenRC & eudev on Arch

#93 2012-11-23 23:33:33

Re: OpenRC & eudev on Arch

#94 2012-11-24 00:17:05

Re: OpenRC & eudev on Arch

#95 2012-11-24 00:27:17

Re: OpenRC & eudev on Arch

#96 2012-11-24 01:06:01

Re: OpenRC & eudev on Arch

#97 2012-11-28 06:24:51

Re: OpenRC & eudev on Arch

#98 2012-11-29 14:50:31

Re: OpenRC & eudev on Arch

#99 2012-11-30 06:12:16

Re: OpenRC & eudev on Arch

#100 2012-12-01 20:29:59

Re: OpenRC & eudev on Arch

Board footer