Bug#727708: init system discussion status
On Sat, Jan 04, 2014 at 06:14:30PM +0000, Ian Jackson wrote:
> (Josh, is there some reason why you replied to the TC list directly
> rather than the bug report ? You should send your messages to the bug
> so they are filed, displayed and archived there. Thanks.)
I don't subscribe to debian-ctte@; I read it via the list archives.
I've been replying using the "Reply to:" links at the bottom of mails,
and then manually copying and quoting the responses. Those links reply
to debian-ctte@lists.debian.org, so unless I manually edit the
destination (which I've done in a few cases where the destination was a
bug report), it ends up going to the list.
It'd be nice if those links paid attention to the
To/Cc/Reply-To/Mail-Followup-To addresses, and otherwise acted like
hitting the reply key in a mail client. I'd also add my voice to the
set of people who have requested mbox archives in the past.
> Josh Triplett writes ("Re: Bug#727708: init system discussion status"):
> > Clint Adams wrote:
> > > As loath as I am to participate in this discussion, I have to ask
> > > if your intent is to suddenly outlaw all the packages which depend
> > > on runit.
>
> Thanks for your intervention which is helpful.
>
> > I think it'd be appropriate to allow dependencies on runit (or another
> > package that contains an implementation of /sbin/init), as long as
> > either the depending package doesn't depend on having /sbin/init be that
> > init (which holds true for runit),
>
> Right.
>
> > *or* if an alternative package exists to integrate with the default
> > init system. For instance, git-daemon-run versus
> > git-daemon-sysvinit versus a hypothetical git-daemon-systemd,
>
> Personally I think this is a pretty nasty way for the git packages to
> have done things, although I understand why. But, regardless, I think
> it's certainly fine from the init system compatibility point of view.
I'm not a big fan of its long insistence on runit (git-daemon-sysvinit
came much later), but I actually rather like the idea of putting init
scripts and systemdiwde configuration in a separate package from
daemons. In the case of git, it makes sense because the daemon lives in
the "git" package, which shouldn't start a daemon. More generally,
though, I wish more packages were split the way Apache is, with one
package containing the daemon and all supporting files, and the other
package containing the configuration for a systemwide daemon. I've
found that particularly useful on many occasions.
> > ... (Note that the latter would work better if upstart stopped
> > conflicting with sysvinit, similar to how systemd can be installed
> > without being init.)
>
> There does seem to need to be some work there.
As I understand it, conflicting with sysvinit and not offering a package
that can be installed in parallel with it was an intentional decision on
the upstart maintainers' parts.
- Josh Triplett
Reply to: