On Thu, Feb 14, 2013 at 7:51 AM, Connor Behan <connor.behan@gmail.com> wrote:
I can't post to arch-dev-public and like Lukas [0] I feel guilty about not getting involved when I should've. Despite the absence of it in the repos do you (Tom) still stand by your claim [1] that there is nothing stopping someone from using initscripts in the far future?
Yeah, the initscripts themselves are just fine. It now comes down to third-party software that to an increasing degree depend on systemd. As you know a few packages link against systemd (ConsoleKit (before it was dropped), NetworkManager and PolKit), and we will soon see all the rc scripts being dropped. All of this could relatively easily be worked around given enough manpower (you'd need a few dedicated people though). However, in the long-run I see this getting increasingly hard as various third-party software drop workarounds that would be needed for initscripts but not for systemd. All-in-all I think staying off systemd is a losing proposition in the long-term, but not due to anything to do with sysvinit/initscripts.
I'll admit that part of the reason I want to stick with initscripts is because I'm a stubborn bastard. But I didn't think the package would be dropped unless a large number of bugs presented themselves.
These 'bugs' are rc scripts being dropped.
The initscripts package I'm using is only two commits behind upstream so it is almost like I'm "testing" the newest version. If I had volunteered to test patches (even though I don't have interesting use cases like RAID / LVM) would there have actually been patches to test?
Probably not. We would need bug reports and people actually writing the patches too. I don't expect a huge amount of work being necessary, but for instance with the recent changes to lvm, it makes sense that something needs to be updated in initscripts too. From time to time there would be similar changes in the future I am sure. That said, the main work to keep initscripts working would be to rc scripts and third-party packages as mentioned above.
There are two forks out now. One aims to add features left and right [2]. The other is a simpler fork that seems more future proof [3]. I am thinking of using the latter. Of course the maintainer could do something stupid later on, but so far he hasn't mentioned any crazy plans like recompiling everything that needs udev. Is this my best bet or do you think there are reasons to stick with the unsupported initscripts from git?
Of the two, I think [3] is definitely the best. That said, I remain very skeptical of any fork that did not first try working with upstream and submit patches on our ML. One important feature of the current initscripts (IMNSHO) which [3] seems to want to drop is compatibility with systemd. This is what will make initscripts simple to maintain, and what will make sure the generic Arch documentation also applies to initscripts to the degree possible, so dropping it is a big mistake in my eyes. That said, I saw a lot of commits in [3] which I would have happily accepted upstream had they been submitted. My general advice would be to find (or create) a fork not based on systemdphobia, but on some practical need. That way you are much less likely to have to deal with irrational and counterproductive goals. Oh, and once you find this practical need, please let me know, as I'd be interested in any use-cases that systemd does not cover :-)
[2] https://github.com/fluxer/initscripts [3] https://bitbucket.org/TZ86/initscripts-fork
Cheers, Tom