Bug#946197: Let's switch to OpenRC?
control: tags -1 +wontfix [2019-12-05 10:32] Thomas Goirand > Source: sysvinit > Severity: normal > > Dear sysvinit maintainers, > > OpenRC is actively maintained upstream, and is a full replacement of sysv-rc, > including many improvements. > > Currently, packages are stuck with long, non-declarative sysv-rc scripts, and > cannot switch to superior runscripts, interpreted by /sbin/openrc-run, which > enable declarative-only scripts. > > So, my proposal is to get rid of sysv-rc provided by sysvinit, in the favor of > OpenRC, so that developers can start replacing their init scripts by superior > runscripts. Personally, I like openrc more that sysv-rc, but as was already pointed, sysv-rc already here and works, while pushing support for another init system into ~1300 packages is hard. And if current General Resolution will favor systemd-only vision of Debian future, then it will become plainly impossible. Tagging as wontfix. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#946197: Let's switch to OpenRC?
> Thomas Goirand writes: > > So, my proposal is to get rid of sysv-rc provided by sysvinit, in the favor of > OpenRC, so that developers can start replacing their init scripts by superior > runscripts. Please don't: runit uses sysvinit scripts as a fallback for a missing runscript (with runscript I mean the native runit init scripts). Also as a side note, I suspect you are a bit underestimating the work needed to replace like ~1000 working scripts into their respective Debian packages. Regards, Lorenzo
Bug#946197: Let's switch to OpenRC?
On 12/6/19 2:30 AM, Benda Xu wrote: > Hi Thomas, > > Thomas Goirand writes: > >>> The last time I looked (years ago), there were features in sysvinit >>> which weren't in OpenRC (yet). IIRC not having concurrent execution of >>> boot scripts was one of the missing features and the reason for e.g. >>> our derivative distribution GRML to not switch to OpenRC some years >>> ago. >> >> OpenRC does have parallel execution of scripts, it works well, but when >> activated, the display output is still a bit ugly. I'm not sure why (I >> haven't investigated). If the issue is just the screen output, then >> probably it can be worked on. > > The ugly output is caused by > /lib/lsb/init-functions.d/20-left-info-blocks from lsb-base. I don't have such file in my system. Has it moved somewhere else? > Thomas Goirand writes: >> Benda Xu wrote: >>> I think it would be time when OpenRC has a systemd .ini parser, to >>> also make use of systemd units. >> >> Do you think this could be written? > > I think so. It's on my agenda. Anyone is welcomed is she wants to > join. This feels like an exciting feature. I wouldn't know where to start, but by all means, if I can help, let me know. Cheers, Thomas Goirand (zigo)
Bug#946197: Let's switch to OpenRC?
Hi Thomas, Thomas Goirand writes: >> The last time I looked (years ago), there were features in sysvinit >> which weren't in OpenRC (yet). IIRC not having concurrent execution of >> boot scripts was one of the missing features and the reason for e.g. >> our derivative distribution GRML to not switch to OpenRC some years >> ago. > > OpenRC does have parallel execution of scripts, it works well, but when > activated, the display output is still a bit ugly. I'm not sure why (I > haven't investigated). If the issue is just the screen output, then > probably it can be worked on. The ugly output is caused by /lib/lsb/init-functions.d/20-left-info-blocks from lsb-base. Thomas Goirand writes: > Benda Xu wrote: >> I think it would be time when OpenRC has a systemd .ini parser, to >> also make use of systemd units. > > Do you think this could be written? I think so. It's on my agenda. Anyone is welcomed is she wants to join. Yours, Benda
Bug#946197: Let's switch to OpenRC?
On Thu, 5 Dec 2019, Thomas Goirand wrote: > Thorsten Glaser > > Dropping sysvinit as it works and as admins know... no. > > Absolutely NOT. > > Thorsten, do you have any point of argumentation besides "it works and > we know it"? That's IMO a bit light... I don’t want to learn a new init system. If I couldn’t have sysvinit I’d likely go with systemd for knowledge reusability, even though it’s a fat, intrusive, pile of things. I’m a BSD person, I never even liked sysvinit and sysv-rc (I ran file-rc for a while but it was not good eiter). I keep it, though, because it’s proven, well-known, low-overhead technology. So, by all means, add OpenRC support, but absolutely not at the cost of something we can currently have. If it’s not possible to have both, I’ll fight tooth and nails against OpenRC. bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in "Notes on Programming in C"
Bug#946197: Let's switch to OpenRC?
Hi Thomas, Thomas Goirand wrote: > > Maybe packages can ship them somewhere else than default, and openrc > > uses dpkg-divert to get them into the expected path if and only if > > openrc is installed. > > Files in /etc/init.d are CONFFILE files. I don't think dpkg-divert works > with CONFFILE files (does it?). I think it does kinda work for most cases, but it is IIRC neither supported nor recommended. Thanks for reminding me of that point! > Even if it did work, we cannot have OpenRC reimplement all of the > init scripts of Debian, these must be carried in each packages. I would expect a fallback as systemd does. Init-scripts are the lowest common denominator as they can be used as fallback for at least the three best-known init systems in Buster. (I have no experience with runit, s6, pid1, tini, dumb-init and maybe the one or two other (container?) init systems of which I forgot the name.) > > P.S.: One of the really cool things about Buster is that it offers 5 > > or 6 different init systems! Now that's what I call diversity. > > How many of them have good support in every package? None anymore. The only one which ever had that was sysvinit. P.S.: Anyone ever has taken metainit into account in this discussion? I must admit, I just stumbled upon it. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#946197: Let's switch to OpenRC?
Hi Alex, Axel Beckert > Thomas Goirand wrote: > > OpenRC is actively maintained upstream, > > Sysvinit is AFAIK maintained upstream again since a year ago or so. So > this is no reason to get rid of sysvinit. Note all the new upstream > releases, Dmitry has uploaded in the past year: > https://packages.qa.debian.org/s/sysvinit.html I never wrote that sysv-rc isn't maintained, that's not the point I'm trying to make. > The last time I looked (years ago), there were features in sysvinit > which weren't in OpenRC (yet). IIRC not having concurrent execution of > boot scripts was one of the missing features and the reason for e.g. > our derivative distribution GRML to not switch to OpenRC some years > ago. OpenRC does have parallel execution of scripts, it works well, but when activated, the display output is still a bit ugly. I'm not sure why (I haven't investigated). If the issue is just the screen output, then probably it can be worked on. > Yes, the fact that these runscripts use the same paths as classic > initscripts in Debian is a pity. Well, yes and no. If we are to keep standard shell script forever, indeed, that's a pity. If we instead decide that it's time to move on, and standardize with runscripts instead, then it's very nice that OpenRC reuse the existing shell script, and allow us to slowly replace them. The pity is to currently have to maintain runscripts *AND* shell scripts, instead of simply deprecating these boring init scripts. > I'd really prefer to continue to have both init systems in parallel > (as long as they're maintained upstream), with different paths so that > both can be used properly. This is exactly what I think should not happen. If we give package maintainers the chance to get rid of these ugly init scritps and replace them by superior runscripts, then probably they will look at systemd alternative differently, and agree to maintain/write runscripts, for example to support non-linux ports. If instead, we keep having old style shell script, which OpenRC also support, I bet copper against gold that mostly everyone wont even bother writing/maintaining runscripts, and keep pestering about init shell scripts. > I'm though not really sure how much impact > it will have to have different paths for the runscripts than upstream. Writing a small patch to have OpenRC prefer a runscript with same name in a different folder over a shell in /etc/init.d shouldn't be very hard, but that's really not what I wish to happen. I really would like a way so that we get rid of the old shell scripts for something more modern and declarative. > Maybe packages can ship them somewhere else than default, and openrc > uses dpkg-divert to get them into the expected path if and only if > openrc is installed. Files in /etc/init.d are CONFFILE files. I don't think dpkg-divert works with CONFFILE files (does it?). Even if it did work, we cannot have OpenRC reimplement all of the init scripts of Debian, these must be carried in each packages. > P.S.: One of the really cool things about Buster is that it offers 5 > or 6 different init systems! Now that's what I call diversity. How many of them have good support in every package? Benda Xu wrote: > I think it would be time when OpenRC has a systemd .ini parser, to > also make use of systemd units. Do you think this could be written? Thorsten Glaser > Dropping sysvinit as it works and as admins know... no. > Absolutely NOT. Thorsten, do you have any point of argumentation besides "it works and we know it"? That's IMO a bit light... Cheers, Thomas Goirand (zigo)
Bug#946197: Let's switch to OpenRC?
On Thu, 5 Dec 2019, Thomas Goirand wrote: > Your thoughts? No. Supporting it as an alternative, granted, not even worth discussing. Dropping sysvinit as it works and as admins know… no. Absolutely NOT. bye, //mirabilos -- Yes, I hate users and I want them to suffer. -- Marco d'Itri on gmane.linux.debian.devel.general
Bug#946197: Let's switch to OpenRC?
Hi Thomas, Thomas Goirand writes: > OpenRC is actively maintained upstream, and is a full replacement of > sysv-rc, including many improvements. > > Currently, packages are stuck with long, non-declarative sysv-rc > scripts, and cannot switch to superior runscripts, interpreted by > /sbin/openrc-run, which enable declarative-only scripts. > > So, my proposal is to get rid of sysv-rc provided by sysvinit, in the > favor of OpenRC, so that developers can start replacing their init > scripts by superior runscripts. > > Note that this doesn't mean we completely get rid of the sysvinit > source package, as we still need a large chunk of it, like for example > the PID 1 in OpenRC can continue to be sysvinit. We also probably need > other components, like for example bootlogd, sysvinit-utils, and maybe > others. > > I'm opening this discussion in the BTS, as I would like to see what > the opinion of sysvinit maintainers is. > > I'm also unsure what would be technically needed to get sysv-rc > automatically be replaced by OpenRC. Maybe we could make sysv-rc > become a metapackage that depends on OpenRC? I think it would be time when OpenRC has a systemd .ini parser, to also make use of systemd units. Yours, Benda
Bug#946197: Let's switch to OpenRC?
Hi, Thomas Goirand wrote: > OpenRC is actively maintained upstream, Sysvinit is AFAIK maintained upstream again since a year ago or so. So this is no reason to get rid of sysvinit. Note all the new upstream releases, Dmitry has uploaded in the past year: https://packages.qa.debian.org/s/sysvinit.html > and is a full replacement of sysv-rc, including many improvements. Is that now the case? The last time I looked (years ago), there were features in sysvinit which weren't in OpenRC (yet). IIRC not having concurrent execution of boot scripts was one of the missing features and the reason for e.g. our derivative distribution GRML to not switch to OpenRC some years ago. > Currently, packages are stuck with long, non-declarative sysv-rc scripts, and > cannot switch to superior runscripts, interpreted by /sbin/openrc-run, which > enable declarative-only scripts. > > So, my proposal is to get rid of sysv-rc provided by sysvinit, in the favor of > OpenRC, so that developers can start replacing their init scripts by superior > runscripts. Yes, the fact that these runscripts use the same paths as classic initscripts in Debian is a pity. > Your thoughts? I'd really prefer to continue to have both init systems in parallel (as long as they're maintained upstream), with different paths so that both can be used properly. I'm though not really sure how much impact it will have to have different paths for the runscripts than upstream. Maybe packages can ship them somewhere else than default, and openrc uses dpkg-divert to get them into the expected path if and only if openrc is installed. P.S.: One of the really cool things about Buster is that it offers 5 or 6 different init systems! Now that's what I call diversity. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#946197: Let's switch to OpenRC?
Source: sysvinit Severity: normal Dear sysvinit maintainers, OpenRC is actively maintained upstream, and is a full replacement of sysv-rc, including many improvements. Currently, packages are stuck with long, non-declarative sysv-rc scripts, and cannot switch to superior runscripts, interpreted by /sbin/openrc-run, which enable declarative-only scripts. So, my proposal is to get rid of sysv-rc provided by sysvinit, in the favor of OpenRC, so that developers can start replacing their init scripts by superior runscripts. Note that this doesn't mean we completely get rid of the sysvinit source package, as we still need a large chunk of it, like for example the PID 1 in OpenRC can continue to be sysvinit. We also probably need other components, like for example bootlogd, sysvinit-utils, and maybe others. I'm opening this discussion in the BTS, as I would like to see what the opinion of sysvinit maintainers is. I'm also unsure what would be technically needed to get sysv-rc automatically be replaced by OpenRC. Maybe we could make sysv-rc become a metapackage that depends on OpenRC? Your thoughts? Cheers, Thomas Goirand (zigo)
