Lets look at the problem little more broad than systemd vs upstart.... the Linux kernel linked stuff.
Freebsd the most intergrated init system is most likely going to be launchd or releation. https://wiki.freebsd.org/launchd Solaris Management Console is the most integrated init system with a Solaris kernel. http://osdyson.org/ exists off to the side of debian at the moment due to debian sticking dominantly with sysvinit. The idea of porting upstart and systemd most likely can be given up on. Since porting either to Freebsd or Solaris is most likely pointlessly. The upstream supported in Freebsd and Solaris for there own init is going to be many times more current on their kernel feature support than any third party. Package maintainers don't want to have to create individual files per init system. Add on the fact there will be multi init systems. How to resolve the issue. Unified generator solution that reads from a common file format and spits out the format the init system requires. Systemd does support generated SourcePath= declare in Unit files. It would be great if upstart would add equal. Yes this is where upstarts contributor agreement is a problem. There is no reason a SourcePath equal declare could not be added to existing LSB systemv init. Like it or not the author of Systemd is correct. Its basically pointless porting init systems across kernels. Init systems to work right have to end up kernel dependant to take advantage of platform particular security features. Also including waffle defining all the unique bends for all the unique platforms like sysvinit did also made life more complex for administrators. Its time to bite the bullet. Systemd vs Upstart if you restrict to Linux only and number of supported Linux Kernel features systemd is clearly winning. Upstart major argument has be in theory portability to other platforms. This is totally not an option. Without portablity in the init system it becomes how well does the init system intergrate with having its configuration files generated so package maintainers can create common file declaring what they need the init system todo for them. Objective package and init system dependency totally unlinked from each other. Packages become dependant on particular versions of generators. Yes the problem here is another project is required. Something that should be part of the standard processes. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
