Re: init script, installed but not activated

On Tue, Oct 06, 2015 at 05:16:55PM -0300, Antonio Terceiro wrote: > On Tue, Oct 06, 2015 at 10:47:28PM +0300, Hleb Valoshka wrote: > > Hi all. > > > > I'm packaging web server for ruby called unicorn. The package installs > > sysv init script, I want to make it installed but not activated > >

Re: init script, installed but not activated

On 08/10/15 04:45, Nick Phillips wrote: > On Thu, 2015-10-08 at 00:36 +0200, Jonas Smedegaard wrote: > >> Debian daemons should by default start - then those not wanting them to >> start can suppress that. The opposite requires far more custom work for >> those who do want daemons to start

Re: init script, installed but not activated

On 08/10/15 09:48, Mat wrote: > I believe that the two use cases (service start by default or not) could > be satisfied for everyone if we removed startup scripts from service > packages and provided them as separate packages. This is effectively already done by some packages: for instance,

Re: init script, installed but not activated

On 08/10/15 12:13, Simon McVittie wrote: > Removing startup scripts from an existing package breaks upgrades, so > for any existing service, the binary package name that matches what we > have now must continue to be the one with the startup scripts. For > instance, it would be OK to split slapd

Re: init script, installed but not activated

On Thu, 08 Oct 2015, Sandro Tosi wrote: > It would be really interesting if someone can share how this can be > done on systemd, as we have reasons to install a service, install its > config files we wrote, but *not* start it by default and/or control if > that service needs to start on a machine

Re: init script, installed but not activated

On Thu, Oct 8, 2015 at 3:47 PM, Don Armstrong wrote: > On Thu, 08 Oct 2015, Sandro Tosi wrote: >> It would be really interesting if someone can share how this can be >> done on systemd, as we have reasons to install a service, install its >> config files we wrote, but *not* start

Re: init script, installed but not activated

> Debian daemons should by default start - then those not wanting them to > start can suppress that. The opposite requires far more custom work for > those who do want daemons to start than it does to suppress startup. > > I believe what you are missing is policy.d: >

Re: init script, installed but not activated

On Thu, 08 Oct 2015 16:29:24 +0100, Sandro Tosi wrote: > On Thu, Oct 8, 2015 at 3:47 PM, Don Armstrong wrote: >> On Thu, 08 Oct 2015, Sandro Tosi wrote: >>> It would be really interesting if someone can share how this can be >>> done on systemd, as we have reasons to install a

Re: init script, installed but not activated

On Thu, 8 Oct 2015 at 08:35 Nick Phillips wrote: > Personally, I'd prefer that packages get a default configuration and > services are never enabled on install. However, I get that some/many > people would prefer that debconf ask them enough questions to configure > a

Re: init script, installed but not activated

Hleb Valoshka <375...@gmail.com> writes: > On 10/6/15, Antonio Terceiro wrote: >> for sysvinit you need to code that manually in the initscript. several >> packages have their initscripts source /etc/default/$package, and check >> for some variable that says whether the

Re: init script, installed but not activated

On Wed, 2015-10-07 at 19:21 +0200, Marc Haber wrote: > On Tue, 6 Oct 2015 22:35:38 +0200, Michael Biebl > wrote: > >If your package does not work unconfigured, a better alternative is to > >check for the existence of a config file. > > This, however, prevents you from

Re: init script, installed but not activated

Quoting Nick Phillips (2015-10-07 22:59:23) > On Wed, 2015-10-07 at 19:21 +0200, Marc Haber wrote: > > On Tue, 6 Oct 2015 22:35:38 +0200, Michael Biebl > > wrote: > > >If your package does not work unconfigured, a better alternative is to > > >check for the existence of a

Re: init script, installed but not activated

Quoting Brian May (2015-10-08 00:11:19) > On Thu, 8 Oct 2015 at 08:35 Nick Phillips wrote: > >> Personally, I'd prefer that packages get a default configuration and >> services are never enabled on install. However, I get that some/many >> people would prefer that

Re: init script, installed but not activated

On Wed, Oct 07, 2015 at 11:28:41AM +0300, Hleb Valoshka wrote: > On 10/6/15, Antonio Terceiro wrote: > > > for sysvinit you need to code that manually in the initscript. several > > packages have their initscripts source /etc/default/$package, and check > > for some variable

Re: init script, installed but not activated

On 10/6/15, Matt Zagrabelny wrote: >>> "--update-rcd-params=..." does not work such way, so we need to >>> introduce workarounds in postinstall script. ... > I believe that practice is now frowned upon since update-rc.d has a > disable verb. I wrote about this above. It

Re: init script, installed but not activated

Hleb Valoshka: > On 10/6/15, Antonio Terceiro wrote: > >> for sysvinit you need to code that manually in the initscript. several >> packages have their initscripts source /etc/default/$package, and check >> for some variable that says whether the service should start on boot

Re: init script, installed but not activated

On 10/6/15, Antonio Terceiro wrote: > for sysvinit you need to code that manually in the initscript. several > packages have their initscripts source /etc/default/$package, and check > for some variable that says whether the service should start on boot or > not. And that's

Re: init script, installed but not activated

On Thu, 2015-10-08 at 00:36 +0200, Jonas Smedegaard wrote: > Debian daemons should by default start - then those not wanting them to > start can suppress that. The opposite requires far more custom work for > those who do want daemons to start than it does to suppress startup. Yes, I'm

Re: init script, installed but not activated

Antonio Terceiro writes: > look at varnish for an example. Please don't. Having START=no, ENABLE=0 or DISABLE_DAEMON_ENABLEMENT=unless-ready was a bad idea when I only had to care about sysvinit. It didn't get any better with hacking it into upstart jobs, I'm not sure

Re: init script, installed but not activated

On Tue, Oct 06, 2015 at 10:35:38PM +0200, Michael Biebl wrote: > Am 06.10.2015 um 22:16 schrieb Antonio Terceiro: > > On Tue, Oct 06, 2015 at 10:47:28PM +0300, Hleb Valoshka wrote: > >> Hi all. > >> > >> I'm packaging web server for ruby called unicorn. The package installs > >> sysv init script,

Re: init script, installed but not activated

On Tue, 6 Oct 2015 22:35:38 +0200, Michael Biebl wrote: >If your package does not work unconfigured, a better alternative is to >check for the existence of a config file. This, however, prevents you from delivering an all-comments default config file in the right place, which

Re: init script, installed but not activated

On Tue, Oct 06, 2015 at 10:47:28PM +0300, Hleb Valoshka wrote: > Hi all. > > I'm packaging web server for ruby called unicorn. The package installs > sysv init script, I want to make it installed but not activated > because unicorn itself is useless, user should configure it and > activate it

init script, installed but not activated

Hi all. I'm packaging web server for ruby called unicorn. The package installs sysv init script, I want to make it installed but not activated because unicorn itself is useless, user should configure it and activate it with "update-rc.d unicorn enable". Or it may installed as dependency for

Re: init script, installed but not activated

Am 06.10.2015 um 22:16 schrieb Antonio Terceiro: > On Tue, Oct 06, 2015 at 10:47:28PM +0300, Hleb Valoshka wrote: >> Hi all. >> >> I'm packaging web server for ruby called unicorn. The package installs >> sysv init script, I want to make it installed but not activated >> because unicorn itself is

Re: init script, installed but not activated

On Tue, Oct 6, 2015 at 3:16 PM, Antonio Terceiro wrote: > On Tue, Oct 06, 2015 at 10:47:28PM +0300, Hleb Valoshka wrote: >> Hi all. >> >> I'm packaging web server for ruby called unicorn. The package installs >> sysv init script, I want to make it installed but not activated