[moving the privite discussion on BTS after D.Bogatov request]
[Lorenzo Puliti]
Hi!
As already anticipated, i'm working on a converter capable of
generating runscripts from systemd units. In fact it's a set
of script for automating the whole process, from the downloading
of the unit up to the creation of a patch suitable for BTS.
The idea is to improve the converter engine and then open a
mass-bug thread on debian-devel with few hundred patch provided.
Unfortunately the task revealed to be more complex than I expect,
so the whole project is still in WIP status, usable but one has to
carefully review and integrate the runscripts.
https://salsa.debian.org/Lorenzo.ru.g-guest/runit-tools/tree/next-0.2
Each script takes as argument a space separated list of basenames as
the one in /etc/init.d/ (but a unit with the basename must exists)
the correct order is fetch --> converter --> finalize --> hackit
I'm looking for ideas, suggestions or bug report to improve the code
( watch out, the converter code is messy, I haven't had the time to do
the cleanup) ; in case you are interested, attached is the list of the
services that i'm using for testing
Among others, i have the following questions:
* does it worth the effort of making a .deb package? ( for now it's just
'git clone' and it's ready for use )
* hackit: - are patches generated like that (with diff) ok for BTS? It looks I can't
preserve the file mode for example.. any better way?
- should I edit the changelog?
* converter: - What to do with Oneshot units? runit-init doesn't need those, but i suspect
runit-sysv does..
- there are hardening features in units files, like "capabilities".. not sure those
are usable in runit, but in case, should i care?
- Do I need to 'set -e' in run script, or it's inherited from invoke-run?
Anyway, if you want to contribute directly I can move the project under /runit namespace in Salsa.
Lorenzo
[Dmitry reply]
I doubt it will be possible. For as little runscripts I managed to push
(tor, irqbalance, acpid), there are always some quirks.
Some experiments. Created runscript for mariadb. It got following line
/bin/sh -c "systemctl unset-environment _WSREP_START_POSITION" || exit 160
But before patch can be submitted to maintainer, automatic testing is
must. I suggest salsa.debian.org/kaction/daemons.
Some suggestions on code:
* you seem to invent yet-another templating engine with those #dep1#
tokens. I suggest you to re-use something already established, like
mustache or jinja2. bin:ionit may be interested.
* please do not print "Starting $NAME". It goes to log, quite
pointless and may confuse scripts/tools that want to analyze log.
* please make scripts return != 0 in case of failure. `./fetch foo'
exiting with 0 is very confusing.
No, I do not think so. You will have to deal with Lintian and FTP team
for little gain.
Well, they are fine, but inconvenient. Ideal patch is one maintainer can
just 'git am'.
Patches generated with diff(1) or debdiff(1), require more work:
* patch -p1 < your_patch.patch
* git add .
* git commit -m '<Invent commit message>'
Personally, I find last part the most tiresome.
May I suggest using git? `debcheckout`, if maintainer uses Salsa, or
`gbp import-dsc apt:foo` otherwise. Extra points for making Salsa merge
request in addition to BTS bug.
Definitely not. Otherwise your patch will stop applying clean after a
release. Also, many (myself included) use `gbp dch` to regenerate
changelog before release.
I think, one-shot units can be translated to
#/usr/bin/env /lib/runit/invoke-run
... do stuff ...
exec sv down .
I ignore them. Actually, when I create runscripts, I read init.d script,
not unit file. Simplier for human, impossible for machine, yeah.
No, it is not. Do you think invoke-run should?
I am fine with patches. Code review is good thing.
PS. You know that I already got runscript into src:tor and src:acpid?