Hi, Steve, first I'd like to thank you for bootstrapping this discussion and proposing the policy text. It's a good start.
I thought I should chime in about what I envision for systemd in Debian so we can make sure we end up with no conflicts between upstart's and systemd's implementations in Debian. I haven't subscribed to the bug report from the start, so I'll try to summarise and copy and paste from various replies in the bug. ]] Kurt Roeckx | A lot of the scripts currently in /etc/rcS.d/ come from the | initscripts package. Is the alternative supposed to implement all the | functionality by those scripts? Or do we expect them to run the | scripts from /etc/rcS.d/ as 9.3.4. seems to suggest? systemd blacklists some of them, but run the rest as normal init scripts that are needed before we reach sysinit.target, then the normal runlevel scripts are run. | /etc/init seems to be a very general directory name for an upstart | job. Can the alternatives use the same job files as upstart? systemd can't, at least. We use /etc/systemd so while I dislike the namespace grab of upstart, it won't cause any problems for systemd. (It also breaks tab completion for those of us who like to run init scripts by hand, which is going to affect everybody, but initramfs-tools already did that so that damage is done already.) >From the proposed policy patch: + SysV init scripts for which + an equivalent upstart job is available must query the output of + the command <prgn>telinit --version</prgn> for the string + <tt>upstart</tt> and avoid running in favor of the native + upstart job. My system actually already has upstart installed, but doesn't use it, so upstart's telinit will have to be fixed to not report «upstart» in its version string if the running init is not upstart. That's slightly orthogonal to this bug report, but it shows that you can't necessarily depend on the output of --version and such to know what's running. This will also affect people on migration from one init system to another. + Dependency-based boot managers for SysV init scripts, such as + <package>insserv</package>, may bypass a given init script + entirely when an equivalent upstart job is present, to avoid + unnecessary forking of no-op init scripts. What happens to the dependency resolution of insserv in that case? I'd much rather have insserv not do anything and the non-sysvinit init system be smart and parse LSB headers rather than insserv seeing that A depends B, but B is missing (since it's provided by a systemd service/upstart job) and then flake out. I'd also like us to forbid depending on implementation-specific scripts such as mountkernfs since there won't necessarily be anything that maps to in a non-sysvinit world. The exception would be if an init script is shipped as part of the init system, so sysv-rc's scripts could have dependencies on mountkernfs, but random daemons could not. A final thing I'd like to get added to the policy text is how standardised facility names are handled. insserv for some reason does not handle init scripts providing $x-display-manager and similar, but requires those to be added to the insserv configuration file. We should either require init implementations to allow providing the standardised facility names or we should put that information somewhere in a a neutral location and format so all init implementations can make use of it. Best regards, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bp2rijxv....@qurzaw.varnish-software.com
