init diversity in Debian
Posted: 2019-09-19 17:49
And he proposes a GR vote to formally decide on support for elogind.Sam Hartman wrote:I'm concerned that removing Elogind commits us to Systemd-based solutions with a very high cost to try new things or change direction. For me that's a step we should be very careful before taking.
Does Devuan supply the missing init scripts for all of those packages?Sam Hartman wrote:There are 1033 non-overridden instances of lintian detecting a service unit without an init.d script [7].
Like that worked so well last time. Well, it did for ass-covering and non-action. For those who are unaware of how the last GR went down, I present dasein's drill-down analysis:Head_on_a_Stick wrote:Sounds like our beloved Leader is keen for that not to happen:And he proposes a GR vote to formally decide on support for elogind.Sam Hartman wrote:I'm concerned that removing Elogind commits us to Systemd-based solutions with a very high cost to try new things or change direction. For me that's a step we should be very careful before taking.
No we don't. And I can't remember any discussion about a problem from the lack thereof. Either those packages aren't being used or those using them know how to create the missing bit. Here are the packages that we touch . . . a little less than 200:Head_on_a_Stick wrote:The bit that caught my eye was this:Does Devuan supply the missing init scripts for all of those packages?Sam Hartman wrote:There are 1033 non-overridden instances of lintian detecting a service unit without an init.d script [7].
Might be worth considering then, quite a few important services are on the list.golinux wrote:No we don't.Head_on_a_Stick wrote:Does Devuan supply the missing init scripts for all of those packages?
If someone squawks, we'll have a look. We really don't need to do extra work if no one is experiencing an issue. Unless, you are offering to take on that project. And btw, if the GR decision been other than ass-covering, that issue wouldn't exist.Head_on_a_Stick wrote:Might be worth considering then, quite a few important services are on the list.golinux wrote:No we don't.Head_on_a_Stick wrote:Does Devuan supply the missing init scripts for all of those packages?
The unit files are declarative in nature (inspired by INI files) so they just list configuration options and leave the heavy lifting to the (C-based) backend. For the alternative init systems shell scripts are used instead and these require more skill to create than a unit file and are consequently more likely to be buggy. So yes, systemd unit files are the best. IMO.sjukfan wrote:Is the systemd unit file the best of them?
Shell scripts can still be replaced, provided a script or executable does their job. When I was still coding for Devuan, I made this suggestion, but it was thrown out of the window.Head_on_a_Stick wrote:For the alternative init systems shell scripts are used instead and these require more skill to create than a unit file and are consequently more likely to be buggy.
Code: Select all
sysvinit/antique init => shell scipt => daemon initialisation process (starts 1 & 2)
1) sysvinit shell scripts
2) unit file execution
Unit files can be integrated into antique inits as shown above.So yes, systemd unit files are the best. IMO.
Only if stripped of the extra features offered by systemd. And anyway why would you want to start units with bash rather than C? Seems like a peculiar choice to me.edbarx wrote:Unit files can be integrated into antique inits
Code: Select all
[ ] Choice 1: F: Focus on systemd
[ ] Choice 2: B: Systemd but we support exploring alternatives
[ ] Choice 3: A: Support for multiple init systems is Important
[ 1 ] Choice 4: D: Support non-systemd systems, without blocking progress
[ ] Choice 5: H: Support portability, without blocking progress
[ ] Choice 6: E: Support for multiple init systems is Required
[ ] Choice 7: G: Support portability and multiple implementations
[ ] Choice 8: Further Discussion
Here's a thought that just came to mind: Did any of those packages exist in Debian Wheezy and, if they did, did they come with an init.d script? If so, perhaps those init.d scripts could be used as is, or with some modifications.Head_on_a_Stick wrote: The bit that caught my eye was this:Sam Hartman wrote:There are 1033 non-overridden instances of lintian detecting a service unit without an init.d script [7].
Looks like there may be a workaround from Jessie Smith:pcalvert wrote:Here's a thought that just came to mind: Did any of those packages exist in Debian Wheezy and, if they did, did they come with an init.d script? If so, perhaps those init.d scripts could be used as is, or with some modifications.
Phil
So it is now OK for developers to start enabling systemd-specific features that won't work with other init systems.Packages should include service units or init scripts to start daemons and services. Packages may use any systemd facility at the package maintainer's discretion, provided that this is consistent with other Policy requirements and the normal expectation that packages shouldn't depend on experimental or unsupported (in Debian) features of other packages. Packages may include support for alternate init systems besides systemd and may include alternatives for any systemd-specific interfaces they use. Maintainers use their normal procedures for deciding which patches to include.
Really I think it's about acceptance. I left Debian because of systemd and wanting to explore other OSs, however, now I'm back with Debian on my main machine. Familiarity is important and I don't want to learn any other OS apart from Debian/Slackware. I have accepted Debian's choice, I don't like it much, but I'm willing to work with it for now.oswaldkelso wrote:Just look at the names of all those ex Debian users that left because of the systemd debacle. People that loved Debian and felt forced out. Feelings were high at the time and the was no chance of reconciliation. Now things have cooled a lot and with the work of some Debian devs and the likes of Devuan that chance of reconciliation could return.
Does this not potentially pull the rug out from under Devuan going forward?Head_on_a_Stick wrote:The GR results are in: https://lists.debian.org/debian-devel/2 ... 00212.html
...
So it is now OK for developers to start enabling systemd-specific features that won't work with other init systems.
That depends on how Devuan are faring for resources, they have a thread about the GR on their forums: https://dev1galaxy.org/viewtopic.php?id=3074Lysander wrote:Does this not potentially pull the rug out from under Devuan going forward?