[arch-projects] [initscripts] So it's gone
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? 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. 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? 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? [0] https://mailman.archlinux.org/pipermail/arch-dev-public/2013-February/024388... [1] https://mailman.archlinux.org/pipermail/arch-dev-public/2012-September/02366... [2] https://github.com/fluxer/initscripts [3] https://bitbucket.org/TZ86/initscripts-fork
On 14/02/13 16:51, Connor Behan 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?
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. 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?
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?
[0] https://mailman.archlinux.org/pipermail/arch-dev-public/2013-February/024388... [1] https://mailman.archlinux.org/pipermail/arch-dev-public/2012-September/02366... [2] https://github.com/fluxer/initscripts [3] https://bitbucket.org/TZ86/initscripts-fork
In all honesty, your best bet is to use systemd. We no longer provide the rc.d files for initscripts (or at least they are slowly disappearing from packages) and more software is beginning to assume booting using it. If you want to stick to initscripts, link [3] is definitely the better choice. I'd assume that it will get the needed fixes for other changes in the Arch userland. Just remember to also keep copies of the rc.d scripts you need too. Allan
On 14.02.2013 07:51, Connor Behan wrote:
I can't post to arch-dev-public
You don't seem to be subscribed so I can't whitelist you.
On Thu, Feb 14, 2013 at 7:51 AM, Connor Behan <connor.behan@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
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... 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@jklm.no> wrote:
On Thu, Feb 14, 2013 at 7:51 AM, Connor Behan <connor.behan@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
On Thu, Feb 14, 2013 at 2:28 PM, Ivailo <xakepa10@gmail.com> wrote:
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?
No, I did not say that at all. If you have rational technical reasons to disagree with systemd there is nothing wrong with that. However, a lot of changes I see floating about in various forks are seemingly based on a desire to avoid systemd at all cost, which is what I am critical of.
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.
In most cases there is no technical reason to avoid linking against systemd. The only thing linking against systemd entails is that you'll have a tiny library installed which will do nothing in case systemd itself is not installed and running. From a technical point of view, forking udev and rebuilding packages to avoid libsystemd-daemon.so is a complete waste of time. Similarly, reimplementing in bash what various systemd tools does for you (tmpfiles++) also does not make any sense from a technical point of view. At best all you have achieved is to duplicate the exact same functionality, but more likely you have introduced some bugs or incompatibilities. Of course, you are free to do all these things. But if your only reason is "i don't want anything from the systemd porject installed on my machine", then I stand by my claim that it is irrational, and that people would be better off using a different project.
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.
Maintaining 200 packages was definitely unnecessary, at worst you should have needed to maintain about four (and now also the rc scripts).
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... to find out what I think even Arch Linux is missing/doing wrong and then judge my work and me personally.
The link was broken, but I think I found the page you intended to link to (.com rather than .co). It was not easy to follow your FAQ, in particular how you differ from Arch. I guess this could be what you mean: "some god damn rules are borke", but it wasn't really specific enough for me to understand. Also you appear to "ship correct manual pages, not like Arch Linux". I don't know what to make of that... Good luck, Tom
On 14/02/13 23:28, Ivailo wrote:
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... 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
Ask and judgement will come... Once I manage to get to your wiki - as you can not even provide a correct address - I see this statement: "But then again, the packages ship correct manual pages, not like Arch Linux." with a link to this package: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=p... So what is your point? We should ship the man pages for the tools we remove? Or it is just you do not understand bash enough to see the binaries were removed right above where the man pages are removed?
Sorry about the link, that would be because of my touchpad changing the cursor position when I hover my hand over it while typing, it's very sensitive and a bit weird.
It was not easy to follow your FAQ .. That would be my fault, English is not my native language but there is the fact that the Wiki is not complete. In fact it is just a temporary solution until the main website up and operational and the only reason to have it is that I can add/remove/change content platform independent. I used to keep some files on my main PC but after a disk failure[1] and no backup files to restore from I'm not taking the chance again.
The approach I choosed, to avoid systemd, is because some software doesn't work (e.g. dbus, networkmanager) even if systemd is present on the system. Check the topics like the one about OpenRC on Arch[2] and more specificly https://bbs.archlinux.org/viewtopic.php?pid=1192933#p1192933 and you will see what I'm talking about so it's not just initscripts that need to be systemd compatible. And to ensure that everything is smooth I had to maintain a lot of packages, and preferable not linked against systemd so if the package relies on a systemd library I can use ldd to check binaries and find which one I have to work on to make my job easier. And about the tmpfiles implementation I think Debian has their own[3] [4] which can be adopted and used within the initscripts. About the manual pages. It appears that you are shipping the logoutd man pages, you are removing the login.1, that's the closest one. And the binary ofcourse. But go list[5] the package and see what you will find. Anyway, the point in my expression on the Wiki is that manual pages should be provided from the software package itself, not the man-pages[6] package which contains reference to /usr/local and such which is not true and is some people say that wrong documentation is worst than none. [1] http://lsd-linux.forums.gs/t15-new-beta-live-cd-iso-is-ready-for-testing-lsd... [2] https://bbs.archlinux.org/viewtopic.php?id=152606 [3] http://comments.gmane.org/gmane.linux.debian.devel.sysvinit/4210 [4] http://packages.debian.org/sid/amd64/debianutils/filelist [5] https://www.archlinux.org/packages/core/x86_64/shadow/files/ [6] https://www.archlinux.org/packages/core/any/man-pages/ On Thu, Feb 14, 2013 at 2:42 PM, Allan McRae <allan@archlinux.org> wrote:
On 14/02/13 23:28, Ivailo wrote:
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...
to find out what I think even Arch Linux is missing/doing wrong and then judge my work and me personally.
http://allanmcrae.com/2012/11/interesting-links-october-2012/#comment-16126
Ask and judgement will come...
Once I manage to get to your wiki - as you can not even provide a correct address - I see this statement:
"But then again, the packages ship correct manual pages, not like Arch Linux."
with a link to this package:
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=p...
So what is your point? We should ship the man pages for the tools we remove? Or it is just you do not understand bash enough to see the binaries were removed right above where the man pages are removed?
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!
@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!
participants (5)
-
Allan McRae
-
Connor Behan
-
Florian Pritz
-
Ivailo
-
Tom Gundersen