Re: [arch-general] On /etc/conf.d deprecation

2012-12-11 Thread Leonid Isaev
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

Re: [arch-general] On /etc/conf.d deprecation

2012-12-11 Thread Karol Babioch
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

Re: [arch-general] On /etc/conf.d deprecation

2012-12-11 Thread Leonid Isaev
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

Re: [arch-general] On /etc/conf.d deprecation

2012-12-10 Thread Gaetan Bisson
[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

Re: [arch-general] On /etc/conf.d deprecation

2012-12-10 Thread Jérôme M. Berger
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

Re: [arch-general] On /etc/conf.d deprecation

2012-12-10 Thread Jérôme M. Berger
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

Re: [arch-general] On /etc/conf.d deprecation

2012-12-09 Thread Tom Gundersen
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.

Re: [arch-general] On /etc/conf.d deprecation

2012-12-09 Thread Dimitrios Apostolou
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

Re: [arch-general] On /etc/conf.d deprecation

2012-12-09 Thread Curtis Shimamoto
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 > >

Re: [arch-general] On /etc/conf.d deprecation

2012-12-09 Thread Dimitrios Apostolou
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

Re: [arch-general] On /etc/conf.d deprecation

2012-12-09 Thread Tom Gundersen
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'

Re: [arch-general] On /etc/conf.d deprecation

2012-12-09 Thread Daniel Micay
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.

Re: [arch-general] On /etc/conf.d deprecation

2012-12-09 Thread Jérôme M. Berger
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

Re: [arch-general] On /etc/conf.d deprecation

2012-12-09 Thread Daniel Wallace
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. > >

Re: [arch-general] On /etc/conf.d deprecation

2012-12-08 Thread Curtis Shimamoto
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 /

[arch-general] On /etc/conf.d deprecation

2012-12-08 Thread Dimitrios Apostolou
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