Hello.
My first question is: do you intend to keep Knot in
EPEL fully up to
date? And how long for? If you are unable to maintain it, who will take
over your task?
Yes, I do. I maintain the package both in Fedora and EPEL. And I usually
update the package immediately after the release. Then the package goes
through the usual update process.
See
https://fedoraproject.org/wiki/EPEL_Updates_Policy for more details.
Till now, this worked very well and nobody complained about rebasing the
package even if there were some backward incompatible changes (e.g, with
respect to configuration file). And I hope this will work in the future as
well.
There cannot be multiple versions of a package in the EPEL repository. I.e,
I cannot maintain both 1.4 and 1.5 in EPEL. If you are interested only in the
last stable version, then EPEL should work for you.
If I was unable to maintain the package (which I hope is very unlikely), then
somebody from Fedora will take over. At the moment, the knot package in EPEL
is owner by Paul Wouters from Red Hat and me.
Btw. we also have a bleeding-edge nightly-builds for of Knot from git master:
https://copr.fedoraproject.org/coprs/jvcelak/knot
Now, what I would like is to have a knot@.service
file, which is a
template. In this template, the ExecStart line would be something like:
ExecStart=/usr/sbin/knotd -c /etc/knot/%i
I understand the motivation. This is completely fine. Nothing prevents you
from creating the knot@.service file in /etc/systemd/system. It will work and
the config will not get overwritten by the package update.
But yes, I can include the knot@.service file in the RPM as well.
However, in order to start/stop/restart these, I would
have to
individually call systemctl for each instance. There is no easy way to
start/stop/restart all of them in a single call. This is where targets
come in. By defining a knot target in a knot.target file, I can group
knot instances. Then, I can simply do:
I didn't know this worked for other operations than start. OK then. :-)
I have described all this here for the benefit of
other users, and to
get feedback on this idea, but I'm happy to send you some template and
target files for inclusion into the package. And if you commit to
maintaining this package in this form, then I would be happy to stop
building our own RPMs, and use yours.
I think your use case is perfectly reasonable. Send me the temple and target
files and I will take a look at them. :-)
Thanks and regards,
Jan