On 08/28/2016 08:37 AM, Bart Schouten wrote: > Sam Hartman schreef op 28-08-2016 1:37: >> Similarly, if the community of people who care about sysvinit is >> unwilling to spend the time keeping it working, eventually sysvinit >> as a whole will be unmaintained and buggy. > > True, but I don't think those conditions are there.
Not yet, but a lot of sysvinit-related stuff still hasn't been adopted after being orphaned. > I mean that the statements: > > a) the scripts need (urgent) maintaining > > and > > b) in the context of the actual maintaining they do need, the help > that is necessary isn't there. > > Are not true. I would agree that in this specific case, a) is not true (there's no apparent problem with them that wasn't already there in Wheezy), but I'm honestly not at all sure about b). To bring out my pet example: with sysvinit systems, in Jessie it's not possible to have /usr on NFS anymore. The reason is that mount.nfs is now linked against a library in /usr. I reported the bug [1] before the release of Jessie (and I only found it because I was testing stuff with sysvinit, I don't use it regularly at all). But nothing happened. Then when the whole monster /usr-merge thread happened on debian-devel half a year ago, I brought up that bug again, and nobody seemed to care either. With systemd this bug doesn't occur, because on systemd systems the /usr partition is mounted in the initrd - so you can indeed boot /usr on nfs with Jessie - but only with systemd. To be fair: the mounting of /usr in initramfs now happens regardless of init system also in Stretch, so the bug will now only appear if you don't use an initramfs. But it was not sysvinit people who made that work, but Ben Hutchings who NMU'd initscripts. [2] Actually, the only people who appear to be improving sysvinit support in Debian at the moment appear to be systemd users. And the only thing I hear from sysvinit users are complaints. > I think the "maintainership requirement" of those scripts are > currently being exaggerated, In this specific case? Probably. When the thread that started this TC bug popped up on debian-devel, I was on your side: those scripts shouldn't have been removed. Heck, I even wrote init scripts for something I packaged recently. (Admittedly, that was a simple daemon and the init script is trivial, see [3].) However, I've been working on something for the last couple of months (on and off) to write some code to make stuff work on sysvinit for one package I maintain, which I wouldn't need to do if I just wanted to support systemd. Currently there's a huge workaround in the package that is awful in every regard. And I really want to get rid of the workaround, because it is detrimental to users in other ways (and the workaround also affects systemd users), and do it properly. But when I read stuff such as this: > ... warehouse of troubles that need a million hours of employment > each year to keep it going ... > - you will hate the day when you discover you've been scammed ... Or, when other people constantly and irrationally bring up libsystemd0 again and again (see the current debian-devel thread), then sorry, these kinds of comments make me lose any motivation in still working on helping people out with sysvinit. It's becoming more and more appealing to me to just say "screw sysvinit users", I don't care anymore. I'm not there yet, but I suspect that I'm not the only one who feels that way, so please, continue with this kind of rhetoric, and see where you'll be at in a few years. > Anyone writing an actual SysV init script would have thought of those > things. That person would have felt responsible for it, because no > one else would do it for you. That person would have built more > intelligence into the startup script. No, sorry, that's simply patently untrue. There are some good init scripts out there, but the vast majority of them are just plain horrible. They kind of work, but they make a lot of assumptions that break in a lot of corner cases. And writing good init scripts is _really_ hard, because shell programming is awful. (Useful, but awful.) Heck, even the skeleton Debian init script is completely useless for use in a Pacemaker/HA environment - because start/stop will _always_ return exit code 0, regardless of whether it worked or not. (Only status returns different exit codes.) With sysvinit I have _always_ had to patch init scripts to return proper error codes when I wanted to use them in a HA environment. (And I've done that since Squeeze, where there was no systemd.) This violates LSB btw. (No, I didn't file a bug against the initscripts package, let alone an MBF against all daemons with this problems, not even before systemd was even a thing during Squeeze times, because it was already very clear to me from just looking at the bug list that nobody seemed to care about maintaining the package properly, and I'd just be wasting my time.) So yeah, for me sysvinit scripts are definitely no fallback. From personal experience I am by _far_ more confident in maintainers getting systemd services right than in them getting init scripts right. (Obviously that doesn't mean that people don't get service files wrong - of course that also happens from time to time.) Regards, Christian [1] https://bugs.debian.org/777547 [2] https://tracker.debian.org/news/741657 [3] http://sources.debian.net/src/open-isns/0.96-4/debian/open-isns-server.isnsd.init/
