On Tue, 11 Dec 2012 17:22:49 +0100
Karol Babioch 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 [1]. con
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 weeks/mont
On Mon, 10 Dec 2012 20:27:38 +1100
Gaetan Bisson 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
> > > own confi
[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
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 betwe
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 cer
On Mon, Dec 10, 2012 at 12:46 AM, Dimitrios Apostolou 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
> distros.
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
locate
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
> >
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 uni
Hi Dimitrios,
On Sun, Dec 9, 2012 at 2:01 AM, Dimitrios Apostolou wrote:
> 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.
[...]
> So I'
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.
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
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.
>
>
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 /
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
16 matches
Mail list logo