@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:
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!