Jonathan Nieder wrote:
> In an ideal world, (i) would be enough [since it determines the
> behavior] and packagers could experiment
Just to be clear: I was reading from the point of view of what a
packager of an ordinary daemon needs to do. But the requirements on
init systems are important, too
Hi,
Steve Langasek wrote:
> On Sat, Mar 05, 2011 at 02:19:12AM -0600, Jonathan Nieder wrote:
>> Maybe policy could allow (but discourage) packages that only support
>> some non-Sys-V init system as long as they include a dependency
>> indicating so?
>
> I don't think that's something that should
Hi Jonathan,
On Sat, Mar 05, 2011 at 02:19:12AM -0600, Jonathan Nieder wrote:
> > + tasks at boot time. However, any package integrating with other
> > + init systems must also be backwards-compatible with
> > + sysvinit by providing a SysV-style init script
> > +
Bill Allombert wrote:
> On Sat, Mar 05, 2011 at 02:19:12AM -0600, Jonathan Nieder wrote:
>> Maybe policy could allow (but discourage) packages that only support
>> some non-Sys-V init system as long as they include a dependency
>> indicating so?
>
> This would be a terrible idea. We would end up w
On Sat, Mar 05, 2011 at 02:19:12AM -0600, Jonathan Nieder wrote:
> Hi,
>
> Steve Langasek wrote:
>
> > Sorry this has taken so long; I spun my wheels on it
> > for some time because I couldn't quite accept that there were so few
> > additional requirements that needed to be specified here!
>
> T
Hi,
Steve Langasek wrote:
> Sorry this has taken so long; I spun my wheels on it
> for some time because I couldn't quite accept that there were so few
> additional requirements that needed to be specified here!
Thanks for your work. :)
[...]
> + tasks at boot time. However, any packa
On Wed, Jan 12, 2011 at 07:38:05PM +0100, Kurt Roeckx wrote:
> On Wed, Jan 12, 2011 at 12:50:21AM -0600, Steve Langasek wrote:
> > On Mon, Jan 10, 2011 at 09:17:33PM +0100, Kurt Roeckx wrote:
> > > What should packages do that want to have their script run
> > > at that time? For sysvinit scripts
On Wed, Jan 12, 2011 at 6:38 PM, Kurt Roeckx wrote:
> On Wed, Jan 12, 2011 at 12:50:21AM -0600, Steve Langasek wrote:
>> On Mon, Jan 10, 2011 at 09:17:33PM +0100, Kurt Roeckx wrote:
>> > A lot of the scripts currently in /etc/rcS.d/ come from the
>> > initscripts package. Is the alternative suppo
On Wed, Jan 12, 2011 at 12:50:21AM -0600, Steve Langasek wrote:
> On Mon, Jan 10, 2011 at 09:17:33PM +0100, Kurt Roeckx wrote:
> > On Sun, Jan 09, 2011 at 08:10:04PM -0600, Steve Langasek wrote:
> > > + method guaranteed to be supported by all init implementations.
> > > An
> > > +
On Mon, Jan 10, 2011 at 09:17:33PM +0100, Kurt Roeckx wrote:
> On Sun, Jan 09, 2011 at 08:10:04PM -0600, Steve Langasek wrote:
> > Also, it's possible that some of the bits I've marked as upstart-specific
> > will also be applicable to systemd and should be moved up a section. I'm
> > not familiar
On Mon, Jan 10, 2011 at 8:17 PM, Kurt Roeckx wrote:
>> + method guaranteed to be supported by all init implementations. An
>> + exception to this rule is scripts or jobs provided by the init
>> + implementation itself; such jobs may be required for an
>> + imp
On Sun, Jan 09, 2011 at 08:10:04PM -0600, Steve Langasek wrote:
> Also, it's possible that some of the bits I've marked as upstart-specific
> will also be applicable to systemd and should be moved up a section. I'm
> not familiar enough with the mechanics of systemd to say whether this is the
> ca
tags 591791 patch
thanks
Hi there,
Attached is a tentative patch for this bug that documents what I think the
requirements are both for alternative init systems in general, and for
upstart in particular. Sorry this has taken so long; I spun my wheels on it
for some time because I couldn't quite
Package: debian-policy
Severity: wishlist
An action item from the upstart BoF today at DebConf is that policy language
needs to be written around upstart jobs before we can start inflicting them
on the archive. The following points should be addressed; they can be split
into separate bug reports
14 matches
Mail list logo
