OpenRC & eudev on Arch

artoo · 2012-12-31 01:33:31

Lone_Wolf wrote:

artoo wrote:
Maybe I didn't get the point across properly.
What I was trying to say, apq's openrc build will stop working as soon as Arch linux moved to /usr completely, scheduled for early 2013. So /sbin & /bin move to /usr/sbin and /usr/bin respectively, like /lib is now a symlink to /usr/lib. /sbin and /bin will only contain symlinks in the future.
openrc build installs to /libexec, which should be avoided according to arch wiki.
Someone from the Arch devs also announced the /sbin/bin move on this thread earlier.
This is why openrc4arch makes use of a prefix install, as well as all plugins.
The prefix is set to /usr like all Arch linux builds.
What you do is back developing the plugins to gentoo state, which doesn't follow the strict /usr move and also has a /lib directory. It'd be easier in this case to download the gentoo packages' init scripts and conf.d files.
In other words, openrc4arch is ready for the /usr move, openrc build is not.
you are partially right, openrc doesn't use /libexec anymore.
The openrc packages do indeed have a /lib directory, and use /sbin /bin .
I haven't seen an announcement yet of the /sbin /bin move to /usr/sbin and /usr/bin on arch-dev-public yet, so there's time.
I choose to use apg packages because they're in AUR, while yours are only in your own repos.
As stated earlier i also disagree with the config directories you choose. i did post a link to the wiki then, but maybe you didn't notice that.
Check out : https://wiki.archlinux.org/index.php/Ar … irectories
Configuration files should be placed in the /etc directory. If there is more than one configuration file, it is customary to use a subdirectory in order to keep the /etc area as clean as possible. Use /etc/{pkgname}/ where {pkgname} is the name of the package (or a suitable alternative, eg, apache uses /etc/httpd/). 

Thanks for the wiki link, I missed that one. Nice.

Allan wrote:

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...

Sounded like its coming.
I also remember having read it somewhere on some arch site info.

Apq seems to have updated the build.

The /usr prefix didn't work from gentoo source, WillamH of openrc helped a lot with fixing this one quickly some time ago.

I run with a separate /usr partition without any problems, which is also lvm volume, root too.

You can safely use my pkgbuild's make, and change the name if you wish.

If only split packages would work on AUR, but over 50 packages to submit is too time consuming.

I made it so that if any plugin providing the same conf.d file name as original arch package, the plugin will have *-openrc appended for both conf.d and init.d files. So, no plugin overwrites arch files.

I also changed back lvm and device-mapper to any arch, packages in testing for i686 now install binaries to /usr.
Hence, all plugins are any arch again.

Btw, I don't want to start a big argument, but why didn't initscripts install files to /etc/initscripts/conf.d ... but /etc/conf.d ... ?
I don't think eg openrc and apache installs can be compared. One is essential init system and core piece of a linux box, while the other is just a software package or service where the stuff wiki mentions should definitely apply.
Apparently, I found gentoo is more consequent with /etc subdirs for services than arch.

Last edited by artoo (2012-12-31 01:53:50)

Lone_Wolf · 2012-12-31 11:17:21

Not sure why initscripts uses those folders, but it may be inherited from unix sysvinit setup .

I've never used gentoo, but i like OpenRC much more then systemd, and it's also better then initscripts was.
I hope to see OpenRC as an alternative init system in arch repos sometime.
There's clearly a small group of people interested/using OpenRC, but currently there are 2 different approaches : packages by apg and packages by artoo.
The 2 approaches are not compatible, but both have good things.

If both methods used the same config directories, servicefiles could be shared and thus lessen the workload.
Barthalion, a TU, mentioned on 1 of the mailing lists he was interested in bringing OpenRC into community.
He also posted in this thread about the config dirs and preferred apg setup unless my memory is wrong.

Artoo, your plugin setup looks to be very flexible : any chance you'll switch to /etc/openrc config dirs ?

Edit :

if you don't want to switch from /etc/ to /etc/openrc , maybe you can modify your plugin packages to support an arbitrary config dir ?
a test for presence of openrc4arch / openrc should be doable, but if that's to complicated an environment variable like _OpenRC_configdir would also work.

Edit2 :
you already use a PREFIX in the source files, so the different paths for runscript in openrc/openr4arch could be selected by the same method.

Last edited by Lone_Wolf (2012-12-31 12:46:53)

artoo · 2012-12-31 14:14:31

Lone_Wolf wrote:

Artoo, your plugin setup looks to be very flexible : any chance you'll switch to /etc/openrc config dirs ?
Edit :
if you don't want to switch from /etc/ to /etc/openrc , maybe you can modify your plugin packages to support an arbitrary config dir ?
a test for presence of openrc4arch / openrc should be doable, but if that's to complicated an environment variable like _OpenRC_configdir would also work.
Edit2 :
you already use a PREFIX in the source files, so the different paths for runscript in openrc/openr4arch could be selected by the same method.

I think I mentioned it earlier, changing the sysconfdir requires some patching of the openrc sources.
I don't plan to touch openrc source, since sysconfdir is not a dynamic configurable path, atm,
But it is not enough to only change the sysconfdir in the make instructions!
You will be on your own with a different sysconfdir, I don't think I will support an altered path as long as the sources don't implement it properly.
I am sorry, but this smells problems. It is in my view more trouble than it serves actually a real and important purpose.

I think you are right with initscripts inheritance, but the very same applies for openrc, hence I am against this change given current upstream source.

If the openrc devs implemented a dynamic sysconfdir, which I doubt it is done it soon, I would reconsider my position of course.
Some plugin scripts also had to have these changes.

An environment variable would defeat the purpose of the prefix in my view.
If you want to change install location, don't use prefix(or leave empty string) or set it to something different.
It'd apply to openrc and plugins.
For example you could set prefix to /opt, and the rc binary would install to /opt and runscripts had #!/opt/bin/runscript in the headers.
The header path appends the prefix, if present

I try to explain briefly how the plugins are configured.
The prefix is set in the make instruction, and if eg prefix=/usr, then everything in eg init.d/* will get prefixed, not only the header path, but also the binary paths.
I made it so, because lvm and device-mapper had unprefixed builds for i686, which is now fixed in testing to prefix=/usr.
It was a truly frustrating experience to figure out the needed prefix install was bugged previously in openrc.

In other words, I wanted to have a plugin make system which can react to a prefixed install of openrc.
These two now go along nicely.
If openrc supported a true configure option for sysconfdir , I'd implement it, but its half baked at the moment, not fully supported.
I consider it, sorry to say, useless cosmetics, and the time to fully implement it could be better spent on plugins.

Openrc also has a make BINDIR and SBINDIR configure option.
Please, don't take offence with this post, it is strictly arguing from a maintenance and gain perspective, while trying to raise the justified and important /usr prefix point.

The bottom line, as long as openrc source doesn't fully support a fully configurable sysconfdir, openrc4arch won't try to change it. There is no point to make the plugins support it, while the core package doesn't use it properly without patching. The plugins share the same openrc make system, just reduced to the minimal.

The main difference between openrc and openrc4arch, besides the prefix install, is probably the sysvinit depend, and initscript compatibility of openrc.
While openrc depends on a custom sysvinit build, openrc4arch depends on plain sysvinit from official arch repos.
While it seems ok to have a different sysconfdir with initscripts compatibility, its useless feature if initscripts conflict with openrc. And frankly, I don't see a reason to prefer unmaintained obsolete initscripts over openrc.
I see a point having eg a "dual boot" systemd/openrc or systemd/initscripts system, but triple boot with one being obsolete?
The point here, while it is entirely right to let openrc depend on a custom sysvinit, it is also a higher chance the user will experience a set back when rebooting if he forgot to change grub.
The transition or testing experience is better with plain sysvinit depend, because it runs out-of-the-box. Install--reboot--done.
Just my opinion.

I don't want to proselytize you or anybody to openrc4arch, but perhaps you can give it a chance and test it?
I'd be interested in feedback, since the services you have trouble with run with the builds as intended.

I also removed any automatic runlevel setting.
It was a nice thing to have while testing, removing and reinstalling, but I concur with the user who mentioned that it should be done manually.
Only syslog-ng modifies the log src in syslog-ng.conf, because it sucks to set it everytime I build and test the packages. All other plugins will only output informations after install what setting or user/group is needed.

Here is a snippet from the openrc source newnet readme:

In the Perfect World (TM) ifconfig should be able to configure everything
about the interface easily * . The BSD family almost get this right and Linux
epically fails.

It is also an issue with the current openrc nuild, it uses newnet make.

Gentoo doesn't use newnet in the ebuilds (yet), I think for good reason.

just saying, the openrc build has a couple of issues to be addressed.

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

prazzb · 2013-01-01 05:38:16

can someone tell me how to have an equivalent "rc.local" ??

edit: got it.... put it in local.d with .start and .stop and it will execute

Last edited by prazzb (2013-01-01 05:54:11)

apg · 2013-01-05 22:06:57

artoo wrote:

patroclo7 wrote:
I think that these things should stay as they are and that, in the case of syslog-ng, *.install files should not touch the configuration files of other packages.
However, all these infos would be useful additions to the openrc archlinux wiki page.
Out of curiosity, why shouldn't .install files do that?

It looks like your syslog-ng package is still doing this, so I will add my own opinions on why this is a very bad idea.

In addition to users possibly wanting to install the package without using it, as patroclo7 pointed out, users may simply not want to use it the way you have in mind. By modifying it from the install file you completely override the user's wishes without giving them a way to reject or easily undo the changes. Even if they undo the change, your package would do it again on an update. Furthermore, you have to keep up with upstream changes to the config file and be very careful not to accidentally break the user's system. Even then you will not know what modifications the user has made, so ultimately you are blindly editing a config file, which is a very bad idea. For a great example of a well intentioned config file update gone very wrong see this thread over at Manjaro: http://forum.manjaro.org/index.php?topi … 69#msg9869

The best thing to do would be to print a short message from the .install file that describes the change necessary and/or points to the wiki: https://wiki.archlinux.org/index.php/Openrc#syslog-ng

The Solutor · 2013-02-10 18:41:51

Hi, first message here just to tanks for your efforts that helped me to keep my Arch systemd free.

I tried both openrc/and openrc4arch and I like more the former approach (all configs in one place are easier to mantain, and the good old init is useful in case of something goes wrong).

Now I have practically anything I use working regardless I boot with OpenRC or init or systemd.

BTW lot of the provided scripts are missing or have the wrong paths.

some examples :

gpm (wrong executable path)

mythtv (missing, but the gentoo one works out of the box)

mysqld (wrong paths, /etc/mysql/my.cnf should be also provided because it contains info needed using the Openrc script)

xdm (intended to launch any dm on gentoo) doesn't really fit well with the arch filesystem organization (on gentoo xdm is always present, no matter if you use kdm or lxdm)

And so on...

BTW aside of those minor problems (for a relatively experienced user) OpenRC works very well and on my system is way faster than systemd and less problematic on the shutdown phase where most ofe the sytemd problems are usually more evident.

I hope the interest on maintaining the openness and the simplicity of Arch linux will not fade and OpenRC will receive some love even if from a minority of the userbase.

P.S. I understand that on *nix world splitting the forces is inevitable, gnome v.s. kde, udev v.s. devfs, ext3 v.s. reiserfs and so on...

I understand less two different projects even where the userbase is minimal like openrc on arch: when little energy is involved one can't waste it, so please artoo and apg join your efforts I will help where and if I can.

Thanks again.

T.S.

artoo · 2013-02-10 21:20:24

The Solutor wrote:

P.S. I understand that on *nix world splitting the forces is inevitable, gnome v.s. kde, udev v.s. devfs, ext3 v.s. reiserfs and so on...
I understand less two different projects even where the userbase is minimal like openrc on arch: when little energy is involved one can't waste it, so please artoo and apg join your efforts I will help where and if I can.
Thanks again.
T.S.

Hi, thank you for the feed back.

I don't want talk all to much about differences, but I say I made from my pov a reasonable proposal to apq, which has gone unanswered.

I tired to summarize the situation, on my openrc4arch blog:

http://openrc4arch.site40.net/

I say it again, I do see a clear advantage of maintaining clearly named packages instead of two separate projects.
I proposed on the blog post a possible solution, but I say clearly, this solution is ugly. The SYSCONFDIR is meant to be /etc and should be /etc.

I plan to enhance the plugins build system a bit to generally make SYSCONFDIR in the initscripts more flexible. But there again, a subdir for openrc conf creates problems.

I will have to catch up with apq's project, I haven't followed it a while for the general lack of time.

But yes, I plan to maintain openrc, and since gentoo forked udev to eudev(already in AUR), the openrc stuff will be expanded to cover it. At least my plan.

What interests me at the moment, how is the view on a modular vs a single package services?

Why would I want init files and config if the the corresponding service is not installed on the system?

@apq

install files already print messages only, I changed it after thread feedback, except for syslog-ng.
I don't see a point not having the syslog-ng.conf changed with the install. If you want to use the package, you will have to change the syslog-ng.conf anyway, as it throws an exception otherwise. But this point should not really be a problem, its easy to remove, if it is such a red flag.

Edit:
I forgot, I created a testing plugin repo, where I already partly implemented a SYSCONFDIR pointing to /etc/openrc where it is necessary. Its far from usable, but an offer to participate.

https://github.com/udeved/openrc-plugins

Last edited by artoo (2013-02-10 21:51:20)

apg · 2013-02-10 22:31:49

artoo wrote:

The Solutor wrote:
P.S. I understand that on *nix world splitting the forces is inevitable, gnome v.s. kde, udev v.s. devfs, ext3 v.s. reiserfs and so on...
I understand less two different projects even where the userbase is minimal like openrc on arch: when little energy is involved one can't waste it, so please artoo and apg join your efforts I will help where and if I can.
Thanks again.
T.S.
Hi, thank you for the feed back.
I don't want talk all to much about differences, but I say I made from my pov a reasonable proposal to apq, which has gone unanswered.
I tired to summarize the situation, on my openrc4arch blog:
http://openrc4arch.site40.net/
I say it again, I do the see a clear advantage of maintaining clearly named packages instead of two separate projects.
I proposed on the blog post a possible solution, but I say clearly, this solution is ugly. The SYSCONFDIR is meant to be /etc and should be /etc.
I plan to enhance the plugins build sstem a bit to generally make SYSCONFDIR in the initscripts more flexible. But there again, a subdir for openrc conf creates problems.
I will have to catch up with apq's project, I haven't followed it a while for the general lack of time.
But yes, I plan to maintain openrc, and since gentoo forked udev to eudev(already in AUR), the openrc stuff will be expanded to cover it. At least my plan.
What interests me at the moment, how is the view on a modular vs a single package services?
Why would I want init files and config if the the corresponding service is not installed on the system?
@apq
install files already print messages only, I changed it after thread feedback, except for syslog-ng.
I don see a point not having the syslog-ng.conf changed with the install. If you want to use the package, you will have to change the syslog-ng.conf anyway, as it throws an exception otherwise. But this point should not really be a problem, its easy to remove, if it is such a red flag.

Edit:
I forgot, I created a testing plugin repo, where I already partly implemented a SYSCONFDIR pointing to /etc/openrc where it is necessary. Its far from usable, but an offer to participate.
https://github.com/udeved/openrc-plugins

Your proposal did not recieve an answer because it did not appear to actually involve any action from me.

The reason the solution in your blog post is ugly is because it is also wrong. There is no need to change the default value of SYSCONFDIR in the makefiles.

If you are not going to maintain your AUR packages, could you please send an email to aur-general asking that they be deleted?

I am not entirely sure what it would mean for us to "join efforts" other than for me to add artoo's service scripts to my package which is unlikely to happen. artoo's service script packages have had a number of issues I consider problematic, including conflicting with the very program they are designed to start and modifying configuration files from the install script. Clearly, they are not (or at least were not at the time) being tested. Furthermore, artoo does not seem to have a firm grasp of the issues involved with packaging OpenRC for Arch (the aforementioned blog post being a good example) and does not appear to pay much attention to detail (I do not think artoo has gotten my name right even once in this entire thread).

artoo · 2013-02-10 23:42:35

apg wrote:

artoo wrote:
The Solutor wrote:
P.S. I understand that on *nix world splitting the forces is inevitable, gnome v.s. kde, udev v.s. devfs, ext3 v.s. reiserfs and so on...
I understand less two different projects even where the userbase is minimal like openrc on arch: when little energy is involved one can't waste it, so please artoo and apg join your efforts I will help where and if I can.
Thanks again.
T.S.
Hi, thank you for the feed back.
I don't want talk all to much about differences, but I say I made from my pov a reasonable proposal to apq, which has gone unanswered.
I tired to summarize the situation, on my openrc4arch blog:
http://openrc4arch.site40.net/
I say it again, I do the see a clear advantage of maintaining clearly named packages instead of two separate projects.
I proposed on the blog post a possible solution, but I say clearly, this solution is ugly. The SYSCONFDIR is meant to be /etc and should be /etc.
I plan to enhance the plugins build sstem a bit to generally make SYSCONFDIR in the initscripts more flexible. But there again, a subdir for openrc conf creates problems.
I will have to catch up with apq's project, I haven't followed it a while for the general lack of time.
But yes, I plan to maintain openrc, and since gentoo forked udev to eudev(already in AUR), the openrc stuff will be expanded to cover it. At least my plan.
What interests me at the moment, how is the view on a modular vs a single package services?
Why would I want init files and config if the the corresponding service is not installed on the system?
@apq
install files already print messages only, I changed it after thread feedback, except for syslog-ng.
I don see a point not having the syslog-ng.conf changed with the install. If you want to use the package, you will have to change the syslog-ng.conf anyway, as it throws an exception otherwise. But this point should not really be a problem, its easy to remove, if it is such a red flag.

Edit:
I forgot, I created a testing plugin repo, where I already partly implemented a SYSCONFDIR pointing to /etc/openrc where it is necessary. Its far from usable, but an offer to participate.
https://github.com/udeved/openrc-plugins
Your proposal did not recieve an answer because it did not appear to actually involve any action from me.
The reason the solution in your blog post is ugly is because it is also wrong. There is no need to change the default value of SYSCONFDIR in the makefiles.
If you are not going to maintain your AUR packages, could you please send an email to aur-general asking that they be deleted?
I am not entirely sure what it would mean for us to "join efforts" other than for me to add artoo's service scripts to my package which is unlikely to happen. artoo's service script packages have had a number of issues I consider problematic, including conflicting with the very program they are designed to start and modifying configuration files from the install script. Clearly, they are not (or at least were not at the time) being tested. Furthermore, artoo does not seem to have a firm grasp of the issues involved with packaging OpenRC for Arch (the aforementioned blog post being a good example) and does not appear to pay much attention to detail (I do not think artoo has gotten my name right even once in this entire thread).

Seriously, you appear to be unable to accept that .install files do not change config files since quite some some time. Yet you somehow insist they do. I named one exception. Have a look in the source before you claim simply things which are not true.

Which issues are you referring to? Conflicting? Which ones? I solved it some time ago by renaming the init files, in case of conflict, the conflicting init file names are *-openrc, and these services do run fine, both on x86_64 and on i686.
Again, have a look in the source before you claim such things.

So please, stop it. I basically told you I won't go with changing to /etc/openrc, and I gave you the reasons.
The change of sysconfdir was basically just a thought, I won't be busy with it. Its not my plan.

I guess you could also change the lines below sysconf, as said not my business.

sys.mk:

SYSCONFDIR?=		${PREFIX}/etc
INITDIR?=		${SYSCONFDIR}/init.d
CONFDIR?=		${SYSCONFDIR}/conf.d
LOCALDIR?=		${SYSCONFDIR}/local.d
SYSCTLDIR?=		${SYSCONFDIR}/sysctl.d

It was basically saying, here is the source and the builds renamed, so we can achieve named openrc packages. Implement the changes to suit your desire to support old initscripts. Hence I created a repo already renamed stuff and created branches for the pkgbuilds, also renamed. Do what you want with it, I am done with you.

I had a look in your service repo, you got eg all 3 cron init scripts, the user is asked to chose only one, no checks if the package is installed, or do you make the arch-services depend on the packages you provide initscripts? I don't think I have to point out the weakness of this all-in-one package approach?

And why the hell does the ubuntu grub add a init=/sbin/init-openrc by default for arch install having standard sysvinit installed? If you have some deeper cross distro involvement, then please say so.

And what is the progress here? You simply avoided any answer, if and when you plan to react to the below message.

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

Last edited by artoo (2013-02-11 00:55:01)

artoo · 2013-02-11 01:07:12

The Solutor wrote:

some examples :
gpm (wrong executable path)
mythtv (missing, but the gentoo one works out of the box)

mysqld (wrong paths, /etc/mysql/my.cnf should be also provided because it contains info needed using the Openrc script)

xdm (intended to launch any dm on gentoo) doesn't really fit well with the arch filesystem organization (on gentoo xdm is always present, no matter if you use kdm or lxdm)

gpm fixed, not committed yet to source

I will add mythtv

mysql, already raises the question I tried to resolve by letting the .install file add the two needed entries.
Atm, it prints what entries are needed in my.cnf. I got the impression, providing a whole file is not wanted, since it'd replace the already existing one.

I run gentoo, and xdm package is not installed. the initscript which falls back to .noxdm is provided by the xserver package on gentoo.

Last edited by artoo (2013-02-11 01:07:51)

x33a · 2013-02-11 08:21:20

apg wrote:

I do not think artoo has gotten my name right even once in this entire thread.

Maybe he uses a font which shows g as q

Jokes aside, if we use /etc instead of /etc/openrc, only the conf.d directory can pose a problem. Because, there can be conflicts with files provided by arch packages and openrc services. Other than that, I don't see any problem arising. Moreover initscripts were finally removed from the repos, so rc.conf won't be a problem.

But, having all openrc files and directories under /etc/openrc does seem much cleaner as one can clearly tell that these directories are related to openrc, which would not be the case if they were under /etc.

As for combining of efforts, the more services are available for users, the more number of users will be interested in trying out openrc. For example I used the lm_sensors service from artoo (not available in the openrc-arch-services-git), and with a few modifications it works fine.

The Solutor · 2013-02-11 10:08:55

artoo wrote:

gpm fixed, not committed yet to source
I will add mythtv.

Ok, thanks.

mysql, already raises the question I tried to resolve by letting the .install file add the two needed entries.
Atm, it prints what entries are needed in my.cnf. I got the impression, providing a whole file is not wanted, since it'd replace the already existing one.

Surely the whole my.cnf file is not needed, But giveen the one from gentoo works w/o any modifications (if the init.d script provide the correct executable path) I believe the best way is to just provide the whole file as my.cnf.openrc or provide it as my.cnf and let the install script to rename the original one as my.cnf.systemd, letting the user/sysadmin to decide if it is best to tweak the original file or to use the new one.

run gentoo, and xdm package is not installed. the initscript which falls back to .noxdm is provided by the xserver package on gentoo

Ok. Im not really a super expert on such things, and for the record I consider the mess of shell script used to launch X on different distros, one of the worst parts of the entire linux ecosystem.

Personally I did the dirty hack of linking tdm (the dm from trinity desktop I use) as xdm and this works form me, btw I believe the entire plugin should be completely rewritten to made it more adherent with the arch standards

x33a wrote:

As for combining of efforts, the more services are available for users, the more number of users will be interested in trying out openrc. For example I used the lm_sensors service from artoo (not available in the openrc-arch-services-git), and with a few modifications it works fine.

Sure.

Atm I've already lost the track of what plugin is coming from one side or from the other, and this is not good,

From what I've seen, all the plugins are agnostic about the directory where they are placed, then there is really no point having two different sources for them. So if we can't agree about a single main package, at least we should have a single plugin source, no matter the personal preference about the main package placement.

Last edited by The Solutor (2013-02-11 10:41:04)

eruditorum · 2013-02-11 10:43:48

Explain me please, what REAL advantages over "systemd" or "arch initscripts" does your "OpenRC on Arch" have? Disk space, working speed, memory footprint, CPU load, ease of use or what?
I don't blame you or anything, just a question.

Last edited by eruditorum (2013-02-11 16:08:38)

Lone_Wolf · 2013-02-11 11:50:48

Over time , systemd has become much more then an init system.
It comes with several 'extras' like journalctl and logind that are impossible to avoid/disable once you boot with systemd.

Also systemd has several static targets/services, that are very hard to disable permanently.
you can mask them, but updates will re-enable them and you have to mask them again.
remotefs and encryptfs are 2 of them.

For my personal situation booting with systemd adds things i don't want / don't need but am stuck with.

If i compare systemd boot with openrcboot on my system, with systemd boot i have a lot more processes running.

Last edited by Lone_Wolf (2013-02-11 11:51:17)

artoo · 2013-02-11 11:58:33

x33a wrote:

apg wrote:
I do not think artoo has gotten my name right even once in this entire thread.
Maybe he uses a font which shows g as q

Right, it indeed looks like a q, if its a g, I apologize for unintended heresy.

The Solutor wrote:

Surely the whole my.cnf file is not needed, But giveen the one from gentoo works w/o any modifications (if the init.d script provide the correct executable path) I believe the best way is to just provide the whole file as my.cnf.openrc or provide it as my.cnf and let the install script to rename the original one as my.cnf.systemd, letting the user/sysadmin to decide if it is best to tweak the original file or to use the new one.
Ok. Im not really a super expert on such things, and for the record I consider the mess of shell script used to launch X on different distros, one of the worst parts of the entire linux ecosystem.
Personally I did the dirty hack of linking tdm (the dm from trinity desktop I use) as xdm and this works form me, btw I believe the entire plugin should be completely rewritten to made it more adherent with the arch standards

x33a wrote:
As for combining of efforts, the more services are available for users, the more number of users will be interested in trying out openrc. For example I used the lm_sensors service from artoo (not available in the openrc-arch-services-git), and with a few modifications it works fine.
Sure.
Atm I've already lost the track of what plugin is coming from one side or from the other, and this is not good,

From what I've seen, all the plugins are agnostic about the directory where they are placed, then there is really no point having two different sources for them. So if we can't agree about a single main package, at least we should have a single plugin source, no matter the personal preference about the main package placement.

I agree, the way a displaymanager start is not ideal. However, I place some hope with wayland which will replace xserver altogether. Eg kwin in kde5 would then act as compositor for wayland.

The my.cnf sounds like a good proposal. I probably (re)implement it.
Same could be done with eg syslog-ng

What plugin version do you use?

I try to summarize the difference of the two openrc projects:

openrc:
- is not ready for the arch /usr merge(please say so if it is)
- changes the default gentoo config dirs in /etc via sysconfdir in make(please say so if it doesn't anymore, eg using INITDIR, CONFDIR etc...)

current openrc-git on github
_makeargs+=(SYSCONFDIR=/etc/openrc)

- monolithic service package

openrc4arch:
- ready for arch /usr merge
- remains default gentoo paths
- modular
- uses groups and virtual packages to solve eg system cron

The reason I prefer default gentoo path, this way a systemd compatibility package could probably be done easily.
Changing path complicates stuff unnecessary, which is technically only needed if you want initscripts support.
I state again, old initscripts also didn't use a subdirectory in /etc. We had /etc/conf.d and /etc/rc.d and rc.conf in /etc.
Openrc keeps this pattern, but uses /etc/init.d instead of /etc/rc.d
I don't quite understand the desire to reinvent the wheel. What is the big deal here to remain proven paths?

Last edited by artoo (2013-02-11 14:49:15)

The Solutor · 2013-02-12 00:08:59

eruditorum wrote:

Explain me please, what REAL advantages over "systemd" or "arch initscripts" does your "OpenRC on Arch" have? Disk space, working speed, memory footprint, CPU load, ease of use or what?

We can argue for a whole day about the systemd advantages and disadvantages, both of them are present (at least for me) this isn't the main point.

The main point is that systemd violates practically any paradigm of the free and open source sw:

1) is imposed from the vertex rather than being pushed from the base. (the classical example of the cathedral and bazar)

2) is a monolithic piece of sw (that mostly works) but something that works is not enough for me: windows or IOS (nowadays) are working too, so if one prefer a way where the os decide for the user, there's no need to look at linux.

3) looking specifically at Arch linux, it's something that represent a definite U turn looking at the KISS principle that is (was ?) its main advantage over most of the other major distros, and unfortunately there isn't any other binary distro so well refined and supported, so fast and simple to use and configure.

4) Whatever someone could argue, linux is about choices: full featured distro or a minimal one, monolithic or modular kernel, kde or gnome, lxde or razor-qt, a 56'' quad HD display or a poor green phosphor terminal, lilo or grub, one partition, half dozen of them, whatever.

So yes. openrc or systemd, why not ?

I'm sorry for the poor English, but I hope you got my point.

back to the topic...

artoo wrote:

I agree, the way a displaymanager start is not ideal. However, I place some hope with wayland which will replace xserver altogether. Eg kwin in kde5 would then act as compositor for wayland.

I hope it too

The my.cnf sounds like a good proposal. I probably (re)implement it.
Same could be done with eg syslog-ng
What plugin version do you use?

This "my" my.cnf (it still works going back to systemd)

# /etc/mysql/my.cnf: The global mysql configuration file.

# $Header: /var/cvsroot/gentoo-x86/dev-db/mysql/files/my.cnf-5.1,v 1.3 2012/02/15 02:07:21 jmbsvicetto Exp $

# The following options will be passed to all MySQL clients
[client]
#password					= your_password
port						= 3306
socket						= /var/run/mysqld/mysqld.sock

[mysql]
character-sets-dir=/usr/share/mysql/charsets
default-character-set=utf8

[mysqladmin]
character-sets-dir=/usr/share/mysql/charsets
default-character-set=utf8

[mysqlcheck]
character-sets-dir=/usr/share/mysql/charsets
default-character-set=utf8

[mysqldump]
character-sets-dir=/usr/share/mysql/charsets
default-character-set=utf8

[mysqlimport]
character-sets-dir=/usr/share/mysql/charsets
default-character-set=utf8

[mysqlshow]
character-sets-dir=/usr/share/mysql/charsets
default-character-set=utf8

[myisamchk]
character-sets-dir=/usr/share/mysql/charsets

[myisampack]
character-sets-dir=/usr/share/mysql/charsets

# use [safe_mysqld] with mysql-3
[mysqld_safe]
err-log						= /var/log/mysql/mysql.err

# add a section [mysqld-4.1] or [mysqld-5.0] for specific configurations
[mysqld]
character-set-server		= utf8
user 						= mysql
port 						= 3306
socket 						= /var/run/mysqld/mysqld.sock
pid-file 					= /var/run/mysqld/mysqld.pid
log-error 					= /var/log/mysql/mysqld.err
basedir 					= /usr
datadir 					= /var/lib/mysql
skip-external-locking
key_buffer 					= 16M
max_allowed_packet 			= 1M
table_open_cache 			= 64
sort_buffer_size 			= 512K
net_buffer_length 			= 8K
read_buffer_size 			= 256K
read_rnd_buffer_size 		= 512K
myisam_sort_buffer_size 	= 8M
language 					= /usr/share/mysql/italian

# security:
# using "localhost" in connects uses sockets by default
# skip-networking
bind-address				= 127.0.0.1

log-bin
server-id 					= 1

# point the following paths to different dedicated disks
tmpdir 						= /tmp/
#log-update 				= /path-to-dedicated-directory/hostname

# you need the debug USE flag enabled to use the following directives,
# if needed, uncomment them, start the server and issue 
# #tail -f /tmp/mysqld.sql /tmp/mysqld.trace
# this will show you *exactly* what's happening in your server ;)

#log						= /tmp/mysqld.sql
#gdb
#debug						= d:t:i:o,/tmp/mysqld.trace
#one-thread

# uncomment the following directives if you are using BDB tables
#bdb_cache_size				= 4M
#bdb_max_lock				= 10000

# the following is the InnoDB configuration
# if you wish to disable innodb instead
# uncomment just the next line
#skip-innodb
#
# the rest of the innodb config follows:
# don't eat too much memory, we're trying to be safe on 64Mb boxes
# you might want to bump this up a bit on boxes with more RAM
innodb_buffer_pool_size = 16M
# this is the default, increase it if you have lots of tables
innodb_additional_mem_pool_size = 2M
#
# i'd like to use /var/lib/mysql/innodb, but that is seen as a database :-(
# and upstream wants things to be under /var/lib/mysql/, so that's the route
# we have to take for the moment
#innodb_data_home_dir		= /var/lib/mysql/
#innodb_log_arch_dir		= /var/lib/mysql/
#innodb_log_group_home_dir	= /var/lib/mysql/
# you may wish to change this size to be more suitable for your system
# the max is there to avoid run-away growth on your machine
innodb_data_file_path = ibdata1:10M:autoextend:max:128M
# we keep this at around 25% of of innodb_buffer_pool_size
# sensible values range from 1MB to (1/innodb_log_files_in_group*innodb_buffer_pool_size)
innodb_log_file_size = 5M
# this is the default, increase it if you have very large transactions going on
innodb_log_buffer_size = 8M
# this is the default and won't hurt you
# you shouldn't need to tweak it
innodb_log_files_in_group=2
# see the innodb config docs, the other options are not always safe
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50
innodb_file_per_table

[mysqldump]
quick
max_allowed_packet 			= 16M

[mysql]
# uncomment the next directive if you are not familiar with SQL
#safe-updates

[isamchk]
key_buffer 					= 20M
sort_buffer_size 			= 20M
read_buffer 				= 2M
write_buffer 				= 2M

[myisamchk]
key_buffer 					= 20M
sort_buffer_size 			= 20M
read_buffer 				= 2M
write_buffer 				= 2M

[mysqlhotcopy]
interactive-timeout

and this is my mysqld plugin

#!/sbin/runscript
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/dev-db/mysql-init-scripts/files/mysql-5.1.67-init.d,v 1.1 2013/01/18 01:51:47 robbat2 Exp $

depend() {
	use net.lo
	# localmount needed for $basedir
	need localmount
}

get_config() {
	my_print_defaults --config-file="$1" mysqld |
	sed -n -e "s/^--$2=//p"
}

mysql_svcname() {
	local ebextra=
	case "${SVCNAME}" in
		mysql*) ;;
		*) ebextra=" (mysql)" ;;
	esac
	echo "${SVCNAME}${ebextra}"
}

start() {
	# Check for old conf.d variables that mean migration was not yet done.
	set | egrep -sq '^(mysql_slot_|MYSQL_BLOG_PID_FILE|STOPTIMEOUT)'
	rc=$?
	# Yes, MYSQL_INIT_I_KNOW_WHAT_I_AM_DOING is a hidden variable.
	# It does have a use in testing, as it is possible to build a config file
	# that works with both the old and new init scripts simulateously.
	if [ "${rc}" = 0 -a -z "${MYSQL_INIT_I_KNOW_WHAT_I_AM_DOING}" ]; then
		eerror "You have not updated your conf.d for the new mysql-init-scripts-2 revamp."
		eerror "Not proceeding because it may be dangerous."
		return 1
	fi

	# Now we can startup
	ebegin "Starting $(mysql_svcname)"

	MY_CNF="${MY_CNF:-/etc/${SVCNAME}/my.cnf}"

	if [ ! -r "${MY_CNF}" ] ; then
		eerror "Cannot read the configuration file \`${MY_CNF}'"
		return 1
	fi

	# tail -n1 is critical as these we only want the last instance of the option
	local basedir=$(get_config "${MY_CNF}" basedir | tail -n1)
	local datadir=$(get_config "${MY_CNF}" datadir | tail -n1)
	local pidfile=$(get_config "${MY_CNF}" pid-file | tail -n1)
	local socket=$(get_config "${MY_CNF}" socket | tail -n1)

	if [ ! -d "${datadir}" ] ; then
		eerror "MySQL datadir \`${datadir}' is empty or invalid"
		eerror "Please check your config file \`${MY_CNF}'"
		return 1
	fi

	if [ ! -d "${datadir}"/mysql ] ; then
		eerror "You don't appear to have the mysql database installed yet."
		eerror "Please run /usr/bin/mysql_install_db to have this done..."
		return 1
	fi

	local piddir="${pidfile%/*}"
	checkpath -d --owner mysql:mysql --mode 0755 "$piddir"
	rc=$?
	if [ $rc -ne 0 ]; then
		eerror "Directory $piddir for pidfile does not exist and cannot be created"
		return 1
	fi

	local startup_timeout=${STARTUP_TIMEOUT:-900}
	local startup_early_timeout=${STARTUP_EARLY_TIMEOUT:-1000}
	local tmpnice="${NICE:+"--nicelevel "}${NICE}"
	local tmpionice="${IONICE:+"--ionice "}${IONICE}"
	start-stop-daemon \
		${DEBUG:+"--verbose"} \
		--start \
		--exec "${basedir}"/bin/mysqld \
		--pidfile "${pidfile}" \
		--background \
		--wait ${startup_early_timeout} \
		${tmpnice} \
		${tmpionice} \
		-- --defaults-file="${MY_CNF}" ${MY_ARGS}
	local ret=$?
	if [ ${ret} -ne 0 ] ; then
		eend ${ret}
		return ${ret}
	fi

	ewaitfile ${startup_timeout} "${socket}"
	eend $? || return 1

	save_options pidfile "${pidfile}"
	save_options basedir "${basedir}"
}

stop() {
	ebegin "Stopping $(mysql_svcname)"

	local pidfile="$(get_options pidfile)"
	local basedir="$(get_options basedir)"
	local stop_timeout=${STOP_TIMEOUT:-120}

	start-stop-daemon \
		${DEBUG:+"--verbose"} \
		--stop \
		--exec "${basedir}"/bin/mysqld \
		--pidfile "${pidfile}" \
		--retry ${stop_timeout}
	eend $?
}
# vim: filetype=gentoo-init-d sw=2 ts=2 sts=2 noet:

finally the (untouched) /conf.d/mysql

# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/dev-db/mysql-init-scripts/files/mysql-5.1.53-conf.d,v 1.2 2011/01/15 17:54:31 robbat2 Exp $

# If you want a non-stock location for the config file, uncomment or update
# either of these as needed. If you do use it, you must make sure that none of
# your socket, pidfile, datadir, logfiles, binary logs, relay logs or InnoDB
# files collide with each other.
MY_CNF="/etc/mysql/my.cnf"
#MY_CNF="${MY_CNF:-/etc/${SVCNAME}/my.cnf}"
#MY_CNF="${MY_CNF:-/etc/mysql/my-${SVCNAME/mysql.}.cnf}"

# Place any additional arguments here that you might need
# Common/useful options:
# --skip-slave-start=1 - For bringing up replication initially
# --server-id=NNN - Server ID for replication
# --skip-networking - lock it down to UNIX sockets only
MY_ARGS=""

# This setting (in seconds) should be high enough to allow InnoDB to do a full
# checkpoint recovery. 900 is the default used in the upstream RPM startup
# scripts. 30 seconds should be sufficent if you just have a tiny <1GiB
# database. After the core startup is done, we wait this long for the UNIX
# socket to appear.
STARTUP_TIMEOUT="900"

# This is how long, in milliseconds, we wait for pidfile to be created, early
# in the startup.
STARTUP_EARLY_TIMEOUT="1000"

# How long (in seconds) should we wait for shutdown?
STOP_TIMEOUT=120

# integer [-20 .. 19 ] default 0
# change the priority of the server -20 (high) to 19 (low)
# see nice(1) for description
#NICE=0

# See start-stop-daemon(8) for possible settings
#IONICE=2

# If defined, --verbose gets passed to S-S-D
#DEBUG=1

# Depending on your usage of MySQL, you may also wish to start it after some
# other services are up. Uncomment the lines below as needed. If these aren't
# enough for you, we encourage you to file a bug, and help us understand how
# you are using MySQL.

# Do your MySQL ACLs refer to hostnames not in your /etc/hosts?
# If so, you need DNS before you can accept connections.
# Avoid dependency circular loops if you use MySQL to power a local DNS server.
#rc_use="dns"
#rc_after="dns"

# Does your MySQL bind to an IP on an interface other than net.lo?
# Alternatively you might wish to specify the exact interface here.
#rc_use="net"
#rc_after="net"

# Do you store your MySQL files on a SAN or other network filesystem, that is
# provided by the netmount init script?
#rc_need="netmount"

# Or from NFS? P.S. This is not a good idea in most cases, but does have some
# valid usage cases, so we provide the option.
#rc_need="nfsmount"

# Should any one of the instances satisfy the requirement for MySQL coming up?
# By default, we say no.
[ "${SVCNAME}" != mysql ] && rc_provide="!mysql"
# But uncomment this next instead if you think it should.
#rc_provide="mysql"

# The conditional above has a false-positive "failure" return value as a
# side-effect, and since it's the last statement, without the next line, this
# script returns failure.
return 0
# vim: ft=gentoo-conf-d et ts=4 sw=4:

the reason I prefer default gentoo path, this way a systemd compatibility package could probably be done easily.
Changing path complicates stuff unnecessary, which is technically only needed if you want initscripts support.
I state again, old initscripts also didn't use a subdirectory in /etc. We had /etc/conf.d and /etc/rc.d and rc.conf in /etc.
Openrc keeps this pattern, but uses /etc/init.d instead of /etc/rc.d
I don't quite understand the desire to reinvent the wheel.

Moving the directories around the filesystem is one of the task that the unix folks are doing better, we should do it too

Jokes aside, i have merely expressed the my personal preference.

Openrc is "alien" on arch so keeping it "jailed" on a single directory make sense IMHO, it's no different that what happened, say on red hat 5 (or so) when the kde arrived, it was confined in the opt directory then, when it became stable and free of conflicts, it was integrated in the usual /usr.

Surely I prefer the binaries placed on the directory I don't like if surrounded by some fully working plugins out of the box, rather than having the directory i like and a lot of broken scripts.

Thats all.

Last edited by The Solutor (2013-02-12 00:48:02)

apg · 2013-02-12 03:56:39

apg wrote:

I am not entirely sure what it would mean for us to "join efforts" other than for me to add artoo's service scripts to my package which is unlikely to happen. artoo's service script packages have had a number of issues I consider problematic, including conflicting with the very program they are designed to start and modifying configuration files from the install script. Clearly, they are not (or at least were not at the time) being tested. Furthermore, artoo does not seem to have a firm grasp of the issues involved with packaging OpenRC for Arch (the aforementioned blog post being a good example) and does not appear to pay much attention to detail (I do not think artoo has gotten my name right even once in this entire thread).

Okay, that was probably a little unfair of me. artoo did find a bug in OpenRC's init.sh and init-early.sh that I had missed and I appreciate that.

artoo wrote:

Seriously, you appear to be unable to accept that .install files do not change config files since quite some some time. Yet you somehow insist they do. I named one exception. Have a look in the source before you claim simply things which are not true.
Which issues are you referring to? Conflicting? Which ones? I solved it some time ago by renaming the init files, in case of conflict, the conflicting init file names are *-openrc, and these services do run fine, both on x86_64 and on i686.
Again, have a look in the source before you claim such things.

I did not mean to insult the current state of your packages. I believe you when you say you fixed the problems I pointed out (with the admitted exception of syslog-ng). I was speaking of past mistakes that would indicate an incomplete understanding of the issues involved with bringing OpenRC to Arch.

artoo wrote:

So please, stop it. I basically told you I won't go with changing to /etc/openrc, and I gave you the reasons.
The change of sysconfdir was basically just a thought, I won't be busy with it. Its not my plan.
I guess you could also change the lines below sysconf, as said not my business.
sys.mk:
SYSCONFDIR?=		${PREFIX}/etc
INITDIR?=		${SYSCONFDIR}/init.d
CONFDIR?=		${SYSCONFDIR}/conf.d
LOCALDIR?=		${SYSCONFDIR}/local.d
SYSCTLDIR?=		${SYSCONFDIR}/sysctl.d

I will say this again, there is no reason to modify the default value of SYSCONFDIR or any other build variable in any of the makefiles.

artoo wrote:

I had a look in your service repo, you got eg all 3 cron init scripts, the user is asked to chose only one, no checks if the package is installed, or do you make the arch-services depend on the packages you provide initscripts? I don't think I have to point out the weakness of this all-in-one package approach?

I have no idea what weakness you see here. There is no way I am going to split all of my service files into separate packages that users will have to individually download and install from the AUR. If a user is not smart enough to figure out that they need to have a program installed before they try to enable it, they probably should not be using Arch and definitely should not be using Arch with an unofficial init system.

artoo wrote:

And why the hell does the ubuntu grub add a init=/sbin/init-openrc by default for arch install having standard sysvinit installed? If you have some deeper cross distro involvement, then please say so.

I have to admit that I have no idea what you are saying here, but I somehow feel as if I have been accused of participating in a conspiracy.

artoo wrote:

And what is the progress here? You simply avoided any answer, if and when you plan to react to the below message.
Allan wrote:
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...

As soon as the Arch devs announce that they are making this switch I will update the build options in my PKGBUILD accordingly. Users are of course always free to enable the necessary build flags in the PKGBUILD any time they wish. They simply need to add:

_makeargs+=(BINDIR=/usr/bin)
_makeargs+=(SBINDIR=/usr/sbin)

artoo wrote:

I try to summarize the difference of the two openrc projects:
openrc:
- is not ready for the arch /usr merge(please say so if it is)
- changes the default gentoo config dirs in /etc via sysconfdir in make(please say so if it doesn't anymore, eg using INITDIR, CONFDIR etc...)
current openrc-git on github
_makeargs+=(SYSCONFDIR=/etc/openrc)
- monolithic service package
openrc4arch:
- ready for arch /usr merge
- remains default gentoo paths
- modular
- uses groups and virtual packages to solve eg system cron
The reason I prefer default gentoo path, this way a systemd compatibility package could probably be done easily.
Changing path complicates stuff unnecessary, which is technically only needed if you want initscripts support.
I state again, old initscripts also didn't use a subdirectory in /etc. We had /etc/conf.d and /etc/rc.d and rc.conf in /etc.
Openrc keeps this pattern, but uses /etc/init.d instead of /etc/rc.d
I don't quite understand the desire to reinvent the wheel. What is the big deal here to remain proven paths?

Please stop rehashing this issue. You have expressed your dislike for /etc/openrc many times and I have already explained why I chose to use it. If you have found some new problem with it that needs to be addressed, then point it out. Otherwise, people can read your previous posts to learn why you dislike it.

Furthermore, your package DOES NOT use default Gentoo paths. You modify both LIBEXECDIR and PREFIX which modifies several paths. In fact, looking at your PKGBUILD on Github, your package even has to patch OpenRC's makefiles to allow you to change PREFIX. None of my packages patch any of OpenRC's sources, although, as I have mentioned before, I have made some patches available on Github that fix some non-critical bugs.

Your openrc4arch package is also not ready for the /usr merge. It has both /usr/sbin/rc and /sbin/rc. Once /sbin becomes a symlink to /usr/sbin your package will actually have a file conflict with itself.

eruditorum · 2013-02-12 07:44:58

The Solutor wrote:

So yes. openrc or systemd, why not ?

Because of ArchLinux Initscripts!!!
Why just not help to continue supporting and enhancing them?

Lone_Wolf · 2013-02-12 10:50:14

Maybe because very few were aware of the existance of this fork ?

OT : Check out the overview page of that fork, you'll see a very interesting name

artoo · 2013-02-12 12:26:49

apg wrote:

apg wrote:
I am not entirely sure what it would mean for us to "join efforts" other than for me to add artoo's service scripts to my package which is unlikely to happen. artoo's service script packages have had a number of issues I consider problematic, including conflicting with the very program they are designed to start and modifying configuration files from the install script. Clearly, they are not (or at least were not at the time) being tested. Furthermore, artoo does not seem to have a firm grasp of the issues involved with packaging OpenRC for Arch (the aforementioned blog post being a good example) and does not appear to pay much attention to detail (I do not think artoo has gotten my name right even once in this entire thread).
Okay, that was probably a little unfair of me. artoo did find a bug in OpenRC's init.sh and init-early.sh that I had missed and I appreciate that.
artoo wrote:
Seriously, you appear to be unable to accept that .install files do not change config files since quite some some time. Yet you somehow insist they do. I named one exception. Have a look in the source before you claim simply things which are not true.
Which issues are you referring to? Conflicting? Which ones? I solved it some time ago by renaming the init files, in case of conflict, the conflicting init file names are *-openrc, and these services do run fine, both on x86_64 and on i686.
Again, have a look in the source before you claim such things.
I did not mean to insult the current state of your packages. I believe you when you say you fixed the problems I pointed out (with the admitted exception of syslog-ng). I was speaking of past mistakes that would indicate an incomplete understanding of the issues involved with bringing OpenRC to Arch.
artoo wrote:
So please, stop it. I basically told you I won't go with changing to /etc/openrc, and I gave you the reasons.
The change of sysconfdir was basically just a thought, I won't be busy with it. Its not my plan.
I guess you could also change the lines below sysconf, as said not my business.
sys.mk:
SYSCONFDIR?=		${PREFIX}/etc
INITDIR?=		${SYSCONFDIR}/init.d
CONFDIR?=		${SYSCONFDIR}/conf.d
LOCALDIR?=		${SYSCONFDIR}/local.d
SYSCTLDIR?=		${SYSCONFDIR}/sysctl.d
I will say this again, there is no reason to modify the default value of SYSCONFDIR or any other build variable in any of the makefiles.
artoo wrote:
I had a look in your service repo, you got eg all 3 cron init scripts, the user is asked to chose only one, no checks if the package is installed, or do you make the arch-services depend on the packages you provide initscripts? I don't think I have to point out the weakness of this all-in-one package approach?
I have no idea what weakness you see here. There is no way I am going to split all of my service files into separate packages that users will have to individually download and install from the AUR. If a user is not smart enough to figure out that they need to have a program installed before they try to enable it, they probably should not be using Arch and definitely should not be using Arch with an unofficial init system.
artoo wrote:
And why the hell does the ubuntu grub add a init=/sbin/init-openrc by default for arch install having standard sysvinit installed? If you have some deeper cross distro involvement, then please say so.
I have to admit that I have no idea what you are saying here, but I somehow feel as if I have been accused of participating in a conspiracy.
artoo wrote:
And what is the progress here? You simply avoided any answer, if and when you plan to react to the below message.
Allan wrote:
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...
As soon as the Arch devs announce that they are making this switch I will update the build options in my PKGBUILD accordingly. Users are of course always free to enable the necessary build flags in the PKGBUILD any time they wish. They simply need to add:
_makeargs+=(BINDIR=/usr/bin)
_makeargs+=(SBINDIR=/usr/sbin)
artoo wrote:
I try to summarize the difference of the two openrc projects:
openrc:
- is not ready for the arch /usr merge(please say so if it is)
- changes the default gentoo config dirs in /etc via sysconfdir in make(please say so if it doesn't anymore, eg using INITDIR, CONFDIR etc...)
current openrc-git on github
_makeargs+=(SYSCONFDIR=/etc/openrc)
- monolithic service package
openrc4arch:
- ready for arch /usr merge
- remains default gentoo paths
- modular
- uses groups and virtual packages to solve eg system cron
The reason I prefer default gentoo path, this way a systemd compatibility package could probably be done easily.
Changing path complicates stuff unnecessary, which is technically only needed if you want initscripts support.
I state again, old initscripts also didn't use a subdirectory in /etc. We had /etc/conf.d and /etc/rc.d and rc.conf in /etc.
Openrc keeps this pattern, but uses /etc/init.d instead of /etc/rc.d
I don't quite understand the desire to reinvent the wheel. What is the big deal here to remain proven paths?
Please stop rehashing this issue. You have expressed your dislike for /etc/openrc many times and I have already explained why I chose to use it. If you have found some new problem with it that needs to be addressed, then point it out. Otherwise, people can read your previous posts to learn why you dislike it.
Furthermore, your package DOES NOT use default Gentoo paths. You modify both LIBEXECDIR and PREFIX which modifies several paths. In fact, looking at your PKGBUILD on Github, your package even has to patch OpenRC's makefiles to allow you to change PREFIX. None of my packages patch any of OpenRC's sources, although, as I have mentioned before, I have made some patches available on Github that fix some non-critical bugs.
Your openrc4arch package is also not ready for the /usr merge. It has both /usr/sbin/rc and /sbin/rc. Once /sbin becomes a symlink to /usr/sbin your package will actually have a file conflict with itself.

Actually, you again talk utter nonsense.
It seems you don't understand the patch, and you haven't tested with and without patch.
Hair raising...

Let me get this straight. You complain I use the /usr/lib dir according to Arch guidelines for pkgbuilds? Sounds a bit childish accusation, so please. It was even discussed on this very thread.
The arch guidelines read, /libexec dir is to be avoided if possible. /lib is a symlink pointing to /usr/lib, and it is possible to avoid /libexec indeed by setting it properly to /usr/lib. Toot toot, what's the problem?
Gentoo and Arch filesystem have differences.
Do you really complain I adapt to proper Arch usage? Seriously?

I do not alter the make files to get prefix working, but to get the runlevels installed. The openrc source required one patch(bug report on gentoo, see pkgbuild), otherwise the source will not install any symlinks in /etc/runlevels and boot fails if you don't add them all manually. It is not like it is meant to be or intended behavior, would you agree?

In other words, the runlevels which are installed without prefix as they should, won't be installed if using prefix.

Well, ready for /usr merge it is, I just have to change one line in the pkgbuild, eventually, all depending on the official repo sysvinit. Now, what is the status of yours concerning /usr merge? My package currently creates a simple symlink /usr/sbin/rc --> /sbin/rc. What is wrong with it?
So I won't have to change the /etc/inittab. I'd think this solution works after /usr merge too.

I was simply asking if you intend to react to the announcement, and when? Now, you managed to answer it finally, so thank you.

I guess you noticed the runscripts of openrc4arch already use /usr/sbin as path which are set via make args.
I find this a good way to deal with /usr requirement, because you won't have to update the initscripts no matter the prefix, it is done by make.
To commit the working runscripts to your repo requires changing back to be non /usr prefixed. See the problem?
So, if you could please consider to prepare for /usr merge already, that would be great.

And btw, your post doesn't deflect from your build using an altered sysconfdir path, you ironically complained about after I wrote some thoughts on that on my blog. Do you want to kid me? Do my package use an altered sysconfdir or yours via make arg?

You make a big deal of using a prefixed install? You can't be serious. All arch packages use it except for eg sysvinit. If you won't change it, it gets installed in /usr anyway but probably won't run.

What you actually say is wrong, I even had an irc chat with WilliamH about the prefix. At the time I switched to /usr prefix, the openrc source was bugged, WilliamH fixed it immediately after I tried his patch, since openrc install was looking for /usr/openrc instead of /run/openrc at boot. His patch went after test directly upstream in master.
Now, the patch I added simply comments out some lines, to make the symlinks install, except you want an unbootable system. This is the part not fixed in openrc source yet(0.11.8 & git version from beginning of year).
You need this patch to make /usr prefix install the runlevels.
The prefix install had caused some headaches and time spent to get it running.
According to willaimH, they will rework the whole prefix make system at some point.
To cut it short, the lines commented out by the patch must not be run if using prefix, or else your install will miss crucial runlevels.

Try a prefix install without patch, and enjoy an unbootable system throwing errors due to missing runlevels.

Would you agree almighty openrc guru, that to be ready for /usr merge, it is important to make openrc a prefixed install? Yes or No?

Thank you for listening.

Last edited by artoo (2013-02-12 17:43:31)

x33a · 2013-02-12 12:35:02

Lone_Wolf wrote:

OT : Check out the overview page of that fork, you'll see a very interesting name

I am not sure if it's *the* Judd Vinet.

artoo · 2013-02-12 12:41:04

eruditorum wrote:

The Solutor wrote:
So yes. openrc or systemd, why not ?
Because of ArchLinux Initscripts!!!
Why just not help to continue supporting and enhancing them?

I would consider openrc way superior to the old arch initscripts.

Actually a bit similar projects, but dependency based services alone is a big plus on openrc side.

The Solutor · 2013-02-12 12:50:34

eruditorum wrote:

The Solutor wrote:
So yes. openrc or systemd, why not ?
Because of ArchLinux Initscripts!!!
Why just not help to continue supporting and enhancing them?

Because I'm not against progress, nor I'm a *nix integralist, I'm against something that is trying to destroy some of the conquest of the open source movement.

I have experimented with eInit when it looked a promising project and was the AD 2007 or so, now openrc looks a modern alternative to the old init which is undoubtedly not adequate anymore to the needs of today computing, and at the same time won't break anything like sysemd is doing.

Also I believe that the plain it doesn't need big efforts (at least now) and surely it has already a wide user base.

That said, as I already wrote, i have the plain init still installed and I try to keep my system working, no matter if booted with init openrc or systemd, so i still care about init even if it is not my main concern.

Last edited by The Solutor (2013-02-12 13:03:21)

eruditorum · 2013-02-12 15:26:23

OKAY. If I get the package now and install it, will it work?

The Solutor · 2013-02-12 16:20:34

eruditorum wrote:

OKAY. If I get the package now and install it, will it work?

It's mostly working but I guess it depends on your setup.

I haven't experimented the network w/o networkmanager because I have no wired network at home.

I use only the cellular nework (since 1998) and I share it via hostapd to the other machines.

With this setup I had only minor problems which I mentioned earlier.

BTW openrc isn't going to destroy your machine it's completely separate from the rest of the system and the

init=/something command, at boot time, is enough to go back and forth from openrc to the other competing init systems.

So, I believe, it's worth trying.

P.S. someone may ask why i don't use systemd but I'm using networkmanager which (more or less) share the same philosophy. Well I don't lke network manager either, but at lest nm doesn't have any comparable alternative, so I consider it way more acceptable.

Last edited by The Solutor (2013-02-12 16:29:48)

Arch Linux

#126 2012-12-31 01:33:31

Re: OpenRC & eudev on Arch

#127 2012-12-31 11:17:21

Re: OpenRC & eudev on Arch

#128 2012-12-31 14:14:31

Re: OpenRC & eudev on Arch

#129 2013-01-01 05:38:16

Re: OpenRC & eudev on Arch

#130 2013-01-05 22:06:57

Re: OpenRC & eudev on Arch

#131 2013-02-10 18:41:51

Re: OpenRC & eudev on Arch

#132 2013-02-10 21:20:24

Re: OpenRC & eudev on Arch

#133 2013-02-10 22:31:49

Re: OpenRC & eudev on Arch

#134 2013-02-10 23:42:35

Re: OpenRC & eudev on Arch

#135 2013-02-11 01:07:12

Re: OpenRC & eudev on Arch

#136 2013-02-11 08:21:20

Re: OpenRC & eudev on Arch

#137 2013-02-11 10:08:55

Re: OpenRC & eudev on Arch

#138 2013-02-11 10:43:48

Re: OpenRC & eudev on Arch

#139 2013-02-11 11:50:48

Re: OpenRC & eudev on Arch

#140 2013-02-11 11:58:33

Re: OpenRC & eudev on Arch

#141 2013-02-12 00:08:59

Re: OpenRC & eudev on Arch

#142 2013-02-12 03:56:39

Re: OpenRC & eudev on Arch

#143 2013-02-12 07:44:58

Re: OpenRC & eudev on Arch

#144 2013-02-12 10:50:14

Re: OpenRC & eudev on Arch

#145 2013-02-12 12:26:49

Re: OpenRC & eudev on Arch

#146 2013-02-12 12:35:02

Re: OpenRC & eudev on Arch

#147 2013-02-12 12:41:04

Re: OpenRC & eudev on Arch

#148 2013-02-12 12:50:34

Re: OpenRC & eudev on Arch

#149 2013-02-12 15:26:23

Re: OpenRC & eudev on Arch

#150 2013-02-12 16:20:34

Re: OpenRC & eudev on Arch

Board footer