[arch-projects] [initscripts] So it's gone

[Ivailo]

Greetings!

I'm the maintainer of the initscripts fork[1] and I already explained my
self in the blog of Allan McRae[2].

> My general advice would be to find (or create) a fork not based on
systemdphobia, but on some practical need.
Are you calling people who don't like systemd insane? Excuse me but you
should pick your words more carefully. The fact that I don't agree with
some implementations decisions about systemd makes me insane? Really?

Yeah, I don't like it being the
all-mighty-init-system-requiring-xyz-and-providing-zyx-replacment but I do
like a few things such as the services format which is very simple to
follow and the fact that basicly there isn't a runlevel (services being
started when needed along with their dependencies).

You probably know about the "LSD" thingy that is floating around the net
but you don't know what I, one of the first to step into it, think about
Arch Linux and the move to systemd. You know that many packages are linked
against systemd so I've tried maintaining packages without systemd support,
or rather that use other udev fork[3], and link packages against it. But
that was because systemd was already in place and even the initscripts rely
on it being installed and some packages shipped in the repositories didn't
support other authentication methods other than the systemd-logind. But
keeping up with Arch Linux was not easy, I was maintaining ~200 packages
and when/if I don't catch up with Arch Linux upgrades things started
falling apart. So I've decided to rely on my own and make my own
distribution. But there are some things you don't know about the LSD
distribution, probably because you haven't searched for more information
about it, please read
http://less-systemd-gnulinux.wikia.co/wiki/Frequently_Asked_Questions#How_is_it_different_than_the_other_.28hundreds.29_of_distributions_out_there.3F
 to find out what I think even Arch Linux is missing/doing wrong and then
judge my work and me personally.

[1] https://github.com/fluxer/initscripts
[2]
http://allanmcrae.com/2012/11/interesting-links-october-2012/#comment-16126
[3]https://bitbucket.org/braindamaged/udev


On Thu, Feb 14, 2013 at 12:42 PM, Tom Gundersen <teg at jklm.no> wrote:

> 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 [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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.archlinux.org/pipermail/arch-projects/attachments/20130214/7aab8ef7/attachment.html>