@Connor Behan No offense taken, it's your call.
On Fri, Feb 15, 2013 at 3:12 AM, Connor Behan <[email protected]>wrote: > On 14/02/13 04:42 AM, Tom Gundersen 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 > 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! > >
