On Mon, 10 Dec 2012 20:27:38 +1100
Gaetan Bisson bis...@archlinux.org wrote:
[2012-12-10 09:14:49 +0100] Jérôme M. Berger:
Tom Gundersen wrote:
However, options that are unrelated to the init-system should not be
specified in ExecStart=, but should be configured in the applications
Hi,
Am 11.12.2012 17:15, schrieb Leonid Isaev:
Do I understand correctly that the plan is to remove conf.d entries
together with corresponding rc.d scrtipts?
You seem to have missed the transition to systemd, see [1]. conf.d will
be removed on a step-by-step basis in next couple of
On Tue, 11 Dec 2012 17:22:49 +0100
Karol Babioch ka...@babioch.de wrote:
Hi,
Am 11.12.2012 17:15, schrieb Leonid Isaev:
Do I understand correctly that the plan is to remove conf.d entries
together with corresponding rc.d scrtipts?
You seem to have missed the transition to systemd, see
Tom Gundersen wrote:
Options related to the init-system, such as where the lock-file is
located should be indicated as an option in ExecStart. The reason this
makes sense is that it must match what is specifid in PIDFile=. The
same goes for any other option that systemd requires to be a
Daniel Micay wrote:
The issue with /etc/conf.d is that it's Arch-specific. There are still
a lot of cases where the packages themselves still provide the units,
but there is a push to get them upstream whenever possible to remove a
lot of burden from the packagers, and share more work between
[2012-12-10 09:14:49 +0100] Jérôme M. Berger:
Tom Gundersen wrote:
However, options that are unrelated to the init-system should not be
specified in ExecStart=, but should be configured in the applications
own configuration file. It has nothing to do with systemd, so for
systemd to just
On Sun, Dec 09, 2012 at 04:01:08AM +0200, Dimitrios Apostolou wrote:
Hello list,
from a reply I got to a bug report (FS#32817, reply is private) I
found out that configuration files in /etc/conf.d are deprecated and
that the supported way is to replicate and customize service files.
Dimitrios Apostolou wrote:
Hello list,
from a reply I got to a bug report (FS#32817, reply is private) I found
out that configuration files in /etc/conf.d are deprecated and that the
supported way is to replicate and customize service files.
Imagine that in /usr unit file the daemon is
The issue with /etc/conf.d is that it's Arch-specific. There are still
a lot of cases where the packages themselves still provide the units,
but there is a push to get them upstream whenever possible to remove a
lot of burden from the packagers, and share more work between
distributions.
On Sat, 8 Dec 2012, Curtis Shimamoto wrote:
On 12/09/12 at 04:01am, Dimitrios Apostolou wrote:
Imagine that in /usr unit file the daemon is being called as binary
-d. So I create the /etc unit file that supersedes it and calls it
as blah -d -n1. Then the package gets updated and the /usr unit
On 12/09/12 at 05:23pm, Dimitrios Apostolou wrote:
On Sat, 8 Dec 2012, Curtis Shimamoto wrote:
On 12/09/12 at 04:01am, Dimitrios Apostolou wrote:
Imagine that in /usr unit file the daemon is being called as binary
-d. So I create the /etc unit file that supersedes it and calls it
as blah -d
Tom, thank you very much for the extensive reply, I've been searching a
lot for the reasoning you explained.
On Sun, 9 Dec 2012, Tom Gundersen wrote:
Speed is not a concern.
The way things should ideally work, IMHO, is:
Options related to the init-system, such as where the lock-file is
On Mon, Dec 10, 2012 at 12:46 AM, Dimitrios Apostolou ji...@gmx.net wrote:
Personally I believe all distros that switch to systemd will add their own
twist to it. Distro-independant Unit files sounds like Utopia. In reality I
expect unit files to be patched for various custom needs of different
Hello list,
from a reply I got to a bug report (FS#32817, reply is private) I found
out that configuration files in /etc/conf.d are deprecated and that the
supported way is to replicate and customize service files.
Imagine that in /usr unit file the daemon is being called as binary -d.
So I
On 12/09/12 at 04:01am, Dimitrios Apostolou wrote:
Hello list,
from a reply I got to a bug report (FS#32817, reply is private) I
found out that configuration files in /etc/conf.d are deprecated and
that the supported way is to replicate and customize service files.
Imagine that in /usr
15 matches
Mail list logo
