Bug#827089: RFS: dh-runit/0.1 ITP
> while I did some work on runit package a while ago, I'm not sure about
> how you want the packages to use your new shiny dh call?
> how do you plan to notify them about it?
> do you plan to open a lot of bugs for packages exposing a runit script?
First of all, runit supports (as policy requires) support for running
/etc/init.d/scripts, so there is no need to make haste. Yes, I plan to
open bugs with patches to provide `runscripts'. As long as there is no
runscript is provided, runit can use init.d script.
dh_runit is now needed by 'getty-run', that now is built
from runit source package.
> I admit, I'm not a fan of too-many-init-systems-to-support, and runit
> is not so far one of the most used...
Sure. As-is in archives it requires determination to migrate on it, so
no surprise. And, as was discussed in upstart RM thread, popularity is
poor metric, when you compare any init system with systemd, which is
installed by default (ugh) and sysvinit, compatibility with which is
mandated by policy.
> but a debhelper script is always something appreciated that can
> simplify things...
Again, dh_runit is dependency of runit now. I would put it into runit
source package, but it would create chicken-and-egg problem.
> another question: I see a lot of activity on git, so you need to
> freeze at some point, and tag the "release", otherwise the sponsor
> won't know when you are ready to go.
If I am correct, master is same as version on mentors. If you insist,
I can make 'release' tag, but I prefer to tag things when they reach
Archives.
--
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io
Reply to: