@Connor Behan No offense taken, it's your call. On Fri, Feb 15, 2013 at 3:12 AM, Connor Behan <connor.behan@gmail.com>wrote:
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. This is why it makes sense to favour systemd as a distro. But I am quite certain the software I use will not introduce systemd as a hard dependency. 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. Exactly. I consider myself capable of "maintaining" a package for initscripts. By that I mean writing patches when / if bugs are reported by other users rather than booting in many configurations and "looking" for bugs. I think this is the approach that Aleksey is taking with fork [3]. 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. I don't think the fork will ever conflict with systemd. It just has the changes that will allow it to still work for the more fanatical users. I will use and contribute to the AUR packages "sysvinit-scripts" and "initscripts-fork" which is fork [3] as suggested. Sorry Ivailo but given the things you want to change, fork [2] does not appeal to me. Good luck with it! 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 My needs are probably the ones you've heard before and do not consider
On 14/02/13 04:42 AM, Tom Gundersen wrote: practical :-). I like editing one file instead of many and I don't just mean rc.conf. I laugh at the proposition that I should split up my xorg.conf file into many xorg.conf.d files. But I shouldn't start a rant. Thanks for the answers!