[arch-projects] [initscripts] So it's gone
teg at jklm.no
Thu Feb 14 07:42:47 EST 2013
On Thu, Feb 14, 2013 at 7:51 AM, Connor Behan <connor.behan at gmail.com> wrote:
> I can't post to arch-dev-public and like Lukas  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  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
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.
> 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
> . The other is a simpler fork that seems more future proof . 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  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 
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  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 :-)
>  https://github.com/fluxer/initscripts
>  https://bitbucket.org/TZ86/initscripts-fork
More information about the arch-projects