Skip to main content ↑ ↓
Topic: Why do runit and openrc packages conflict? (Read 8794 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Why do runit and openrc packages conflict?

Reply #15 –
Quote from: ####### – on
Perhaps '-dd' as previously suggested might be better as it would probably work better with updates. I do see a point to this though, firstly you would expect to be able to install more than one browser, desktop, text editor, theme, kernel and so on, and not have to uninstall and reinstall them every time you felt like a change. And if you were developing and testing something and wanted to try it out now and again, and have easy access to study the file structure, file contents and documentation of different inits, it would be genuinely useful to have the latest version of each installed and automatically updated. It would make a simple backup too, if you could chroot in and swap inits with a single command. Then you could mess about with one init and easily recover if you broke it. But then you can probably still do all this as things are now with a few more commands.


You are a bit comparing different things, a browser and applications are not in the same category as a system software such as the init system.
Compare the init system with a motor of a car, you would probably not decide tomorrow to swap out the motor of your car, and two days later back to the old motor again.
To test eg init related stuff, you simply have two vbox installs with each init system.
To avoid any confusion on the user's end, we simply do not allow two init systems installed in parallel, as any other distro also does, for good reasons. In simple terms, there is a choice to make which init system you want to use.

Re: Why do runit and openrc packages conflict?

Reply #16 –
Some distros actually insist that one init remains on the system when another is installed - surely that idea will never catch on. Personally I've been quite happy using just OpenRC, I think the default shutdown sequence is more considerate than most, but if I felt like trying something else then it's useful to know that there are no conflicting files.

Re: Why do runit and openrc packages conflict?

Reply #17 –
Are you sure you are not confusing init system with service supervisors?  Runit for example. as a service supervisor, exists even in Debian repositories and could work on top of systemd.  Probably fedora and rehl.  OpenRC was used on top of sysv with the same role.  But two init systems together active can only be trouble, I think.

Re: Why do runit and openrc packages conflict?

Reply #18 –
I think before we continue this discussion we need to agree on what is an init and what is an init system since I think there's a confusion.

For instance, is suckless init a complete init system?
now only the dinit guy in artix

Re: Why do runit and openrc packages conflict?

Reply #19 –
Quote from: konimex – on
For instance, is suckless init a complete init system?
>suckless
>complete system
I would say no suckless program is a system, it is only a program serving some purpose. Sinit provides only init, all other is on users side. It doesn't even provide shutdown/reboot commands itself. I don't even speak about service supervisor (but there is svc as an example).
P.S. I really use sinit as my main init on both my Artix systems. For me it works as fast runit does
ARMtix

Re: Why do runit and openrc packages conflict?

Reply #20 –
Quote from: phoenix_king_rus – on
>suckless
>complete system
I would say no suckless program is a system, it is only a program serving some purpose. Sinit provides only init, all other is on users side. It doesn't even provide shutdown/reboot commands itself. I don't even speak about service supervisor (but there is svc as an example).
P.S. I really use sinit as my main init on both my Artix systems. For me it works as fast runit does

I'm only asking if sinit is a complete "init system" because of #######'s statement earlier "Some distros actually insist that one init remains on the system when another is installed" (I actually don't know what "init" refers to, PID1 or "init system"). Yes, it is impossible to run two simultaneous init (as in PID1), but it is possible to have multiple init systems, though only if you have a very specific/made-up purposes (and it would be redundant (and dangerous), in almost every case).

Anyway, you mentioned that you used sinit as PID1, since it's supposed to be OS-agnostic, it'd make sense to not include any reboot/shutdown command by itself since it's a kernel syscall (it would differ between Linux and... say, OpenBSD).

Since a complete init system mainly consists of init/PID1 and rc (and/or service management system), if you're using sinit, what's your /etc/rc? Hand-made?
now only the dinit guy in artix

Re: Why do runit and openrc packages conflict?

Reply #21 –
Quote from: konimex – on
Since a complete init system mainly consists of init/PID1 and rc (and/or service management system), if you're using sinit, what's your /etc/rc? Hand-made?
I wrote service launcher inspired by svc to work with sinit. This way rc.init and rc.shutdown become very simple scripts
However i also need ubase for some utilities
ARMtix

Re: Why do runit and openrc packages conflict?

Reply #22 –
I don't think any of these complexities really need to inform the decision, my attitude towards this is simply that packages that do not have conflicting files should not conflict. Any kind of arbitrary limitation over the user whether or not you see a use case feels unnecessary.

Re: Why do runit and openrc packages conflict?

Reply #23 –
Quote from: E5ten – on
I don't think any of these complexities really need to inform the decision, my attitude towards this is simply that packages that do not have conflicting files should not conflict. Any kind of arbitrary limitation over the user whether or not you see a use case feels unnecessary.


That 's fine, but bottom line is, we will not change it, because how we set the init symlink to either openrc-init or runit-init.
Other reasons have been stated as well allowing two init systems in parallel spells trouble for users, needless trouble.

Re: Why do runit and openrc packages conflict?

Reply #24 –
I am a bit *pissed of* by the attitude "i cannot see a use case, so I forbit it".

Well, one core of hacking is to put things together in a way they were not designed for initially. Be it to create functionality, to suit some corner-case use case, for educational purposes, ...

And hacker-friendly systems should not forbit anything artificially because some user-experience designer thinks that for the thought-of use case something else is not needed. As long as something else also does not harm, why to forbit something else?

If someone has 2 init systems in parallel it is his conscious choice. Files just lying around don't harm the system in any way.

And having two different browsers, text editors, kernels or init systems is from my point of view a similar thing, just on a different level. And when your working level is on the base of init system/ system basics, why not having more than one, as someone who works daily with the browser?

Re: Why do runit and openrc packages conflict?

Reply #25 –
Quote from: dreieck – on
I am a bit *pissed of* by the attitude "i cannot see a use case, so I forbit it".

Well, one core of hacking is to put things together in a way they were not designed for initially. Be it to create functionality, to suit some corner-case use case, for educational purposes, ...

And hacker-friendly systems should not forbit anything artificially because some user-experience designer thinks that for the thought-of use case something else is not needed. As long as something else also does not harm, why to forbit something else?

If someone has 2 init systems in parallel it is his conscious choice. Files just lying around don't harm the system in any way.

And having two different browsers, text editors, kernels or init systems is from my point of view a similar thing, just on a different level. And when your working level is on the base of init system/ system basics, why not having more than one, as someone who works daily with the browser?


There is a difference between 'forbidden'  and 'unsupported'

If a user really wants two init's installed it would be fairly trivial to edit the PGKBUILD's and a few scripts and symlinks to make it possible for yourself. You could share the instructions on how it's achieved on a forum topic. If that user cannot do it they could pay someone who can to do it or ask other users for help etc.

Nothing is forbidden. Do what you want with your box. But you can't expect distro's to support every use case.

Re: Why do runit and openrc packages conflict?

Reply #26 –
Quote from: dreieck – on

If someone has 2 init systems in parallel it is his conscious choice. Files just lying around don't harm the system in any way.



I await your solution to what default init grub is supposed to start.
I would encourage you to read up a bit on how the boot process works.

Re: Why do runit and openrc packages conflict?

Reply #27 –
Quote from: dreieck – on
I am a bit *pissed of* by the attitude "i cannot see a use case, so I forbit it".

It's not forbidden, it's made to conflict and that's a huge difference. You can install all the scripts you want, only you'll have to use the right pacman options. OpenRC and runit themselves are an exception, for reasons explained thoroughly. I suggest you edit the PKGBUILD of either of them and hack it the way you want.

Re: Why do runit and openrc packages conflict?

Reply #28 –
Quote from: artoo – on

I await your solution to what default init grub is supposed to start.

Grub starts Linux.

Linux starts the first process, by default /sbin/init, but can be configured with kernel command line parameters (init=<path-to-executable>).

Choosing the init system can be done e.g. by having /sbin/init be a symlink pointing somewhere or by specifying parameters to Linux, can be done in the bootloader configuration.

Grub does not start any init.

Re: Why do runit and openrc packages conflict?

Reply #29 –
Seems like you're splitting hairs over semantics here. Grub (or any other bootloader) tells Linux what init to start.