"convert to openrc-run" on stable

[tert]

Hi. I just synced to latest on stable and updated openrc. An immediate problem is the "convert to openrc-run" warnings rolling off the screen.

After some searching, it seems that the warnings are just a tweak on openrc and not to be worried about, at least for now. However I do like to raise a few concerns and hear the community about this subject.

My observations: (correct me if im wrong)
1 gentoo is one of the few popular distros offering openrc; the majority have adopted systemd exclusively
2 openrc is maintained by debian maintainers
3 debian switched to systemd

This seems like a perfect formula for disaster. If i know anything about software development (admittedly i don't know very much), when maintainers are not responsible for their project and potentially have incentives to screw it, we are gonna end up with a poorly maintained if not intentionally screwed project. In this case, the project might be openrc.

Or maybe im cutting out paper dinosaurs.

[eccerr0r]

Gentoo is supporting openrc and I thought Gentoo was now the maintainers of OpenRC so if you keep using Gentoo, OpenRC will be kept up to date. However there will be limited support for binary packages that require systemd for no good reason. There's not much that can be done here depending on the package.

Please report bugs and the exact packages that generate warnings on bugs.gentoo.org. They may need to be brought upstream to the particular package but I thought most of them were managed by the Gentoo package maintainers.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[tert]

[eccerr0r]

Actually you got me wrong, and seems your facts are skewed. Gentoo maintains OpenRC and has / will keep vested interest in it.

But Gentoo does not have the clout to force packages to update their packages to the new standard. I'm sure that OpenRC will continue to support the existing standards for a long time because too much will break for no good reason, other than making the OpenRC interface look better/work faster.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[tert]

[eccerr0r]

Apparently so, but is it a problem when the old standards are still maintained, at least for the time being?

Or are you suggesting that software should stay static and never improve?

Systemd clearly has some benefits to standard init. Those who deny that fact are simply people who think the drawbacks outweigh the benefits. They see these benefits and want to try to incorporate some of these advantages into older init systems. However some of these features that systemd provides cannot simply be patched in, it requires a paradigm shift.

Some of these hacks to openrc are probably due to these improvements, trying to ensure that openrc service status tracking matches that of systemd when possible. Traditional sysvinit scripts simply don't care if services die or stopped, and that actually can be a problem that could be simply an annoyance to major dependency problems that can be tough to debug.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[tert]

[eccerr0r]

No it isn't, but it is about software progress to change APIs...
Name change is an API change, most likely due to making all API calls consistent, making a cleaner interface to openrc.

I guess it has been discussed: https://forums.gentoo.org/viewtopic-t-1007118-start-0-postdays-0-postorder-asc-highlight-runscript.html Turns out to be filename collision. Goes to show who gets to change filenames when there's a collision with some other package...Gentoo bends :(
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[mv]

[tert]

[Yamakuzure]

[Naib]

[miket]

The connection to Debian came indirectly via using the name runscript as an executable. The serial-communication program Minicom (net-dialup/minicom) has a scripting feature. The program is useful and the script feature is helpful. The problem is that the executable that runs the scripts is called runscript. That's wayy too generic of a name. Running a script? What kind of script do you mean? Tons of packages have their own scripting languages. The name runscript carries no implication of which package's script it will run. It is a poor choice of a name. Minicom, however, has been around a long time. Even if most people's systems don't have minicom installed, the program has a long tail.

Debian, by the way, is the Minicom upstream.

While the execution of scripts is only ancillary to the use of Minicom, it's a central requirement of the use of OpenRC. An early decision in the development of OpenRC was to repeat the same mistake in naming the executable to run its scripts (which, by the way, are entirely unlike Minicom scripts). Most of the time, this was not a problem because of the infrequent deployment of Minicom and the fact that the executables have always been installed in different places.

• OpenRC: /sbin/runscript
  
• Minicom: /usr/bin/runscript
  

For almost anyone at the command prompt, this was not a problem: root using runscript from the Bash prompt would run an OpenRC script; a normal user entering the same command would run a Minicom script. The only hangup would be if root wanted to run a Minicom script from the command line (probably not a good idea anyway). Script shebang lines would be unaffected in either case:

[eccerr0r]

I happen to still use minicom (but don't use its runscript) so it is not a useless package. While I don't like the fact that the later and more popular OpenRC must change, I think it was the right call to change it versus minicom.

Glad there's no lawsuit on this, if there was a trademark lawsuit, minicom would have won due to being first, so the effect would have been the same.

I don't think running minicom as root is that big a deal, usually it's only used for debugging embedded devices where it's probably a very guarded environment anyway. Getting the permissions just right on minicom is probably the other pain anyway for something that's not going to be used by general users (who ever dials up BBSes anymore?) Granted if the device is sending zmodem requests then it could be a cause for alarm...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[Myu]

Hello there,

I don't know if I should open a bug for it but openrc-0.21.3 render my LUKS home partition unmountable at boot time, same "convert to openrc-run" issue, I had to downgrade to 0.19.x
_________________
Gentoo stable with bits of ~amd64 // Xfce 4.13 + Compiz Reloaded.

[Naib]

runscript is too generic in itself to exist system wide. for a binary called "runscript" within some openrc directory sure
_________________

[mv]

[tert]

Thanks for the reply everyone. This thing turns out to be quite fishy. It is a relief to know that openrc is maintained by gentoo.

[tert]

[Myu]

[mv]

[Myu]

Hello mv, thanks for your input

I've made a test with openrc-0.21.3 and upon reboot, I'm prompt to enter my LUKS password as usualy but the upper line says :

[eccerr0r]

You can hack /etc/init.d/dmcrypt to use openrc-run and try again, then you can say whether it really was the issue...
Looks like some deeper debug is needed.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[Myu]

[krinn]

Like mostly all changes done in a sane way, before dropping /sbin/runscript support, you should have a transition step, where you keep item1 and in the same time have item2 set ; after some time you drop item1 and keep using item2, a delay that allow anyone to stop using item1.