Side note from bystander: in this, fascinating thread I mention one,
small thing: systemd is disputed here only as primary init system.
But systemd is on fast track to evolving into something bigger and
larger than process supervisor - something like universal platform
for LinuxOS, like - I don't
On Thu, 2014-01-02 at 14:27 -0800, Steve Langasek wrote:
> On Thu, Jan 02, 2014 at 09:50:58AM -0700, Bdale Garbee wrote:
> > Josselin Mouette writes:
>
> > > It shouldn’t come as a surprise that it is hard for developers to
> > > respect the TC’s decisions when we see disrespectful sentences like
On Thu, 02 Jan 2014, Steve Langasek wrote:
> our users. If we decide for systemd, what do you think is the right way to
> mitigate such problems for jessie? Some of these issues are only going to
> be seen once people start making use of systemd in anger with their existing
> server configs (e.g.
On Thursday 02 January 2014 14:27:14 Steve Langasek wrote:
> For several years the GNOME Team ignored section 9.7 of Policy, concerning
> integration with the MIME handling system. They did this in favor of
> implementing the related freedesktop.org on the grounds that the fd.o
> standard is techn
Sune Vuorela writes ("Bug#727708: init system other points, and conclusion"):
> I've ignored the menu system as a part of the KDE Team. And I have a plan to
> even more aggressively ignore it (as in, hide it from the menu).
>
> Both things are ancient relics that should have been dealt with by re
[dropping #727708 as it is getting off-topic]
Le Fri, Jan 03, 2014 at 12:22:44PM +, Ian Jackson a écrit :
>
> Our menu arrangements have been unsatisfactory for some time and I for
> one would certainly be open to change. Now is probably not the right
> time for this, but maybe after we've d
On 01/03/2014 01:25 AM, Russ Allbery wrote:
> As I mentioned in some of my previous notes, I was unable to evaluate
> OpenRC in a meaningful way during my general experiments for a few
> reasons. My impression was formed based on previous discussion and what
> documentation I could find, which was
Thomas Goirand writes ("Bug#727708: additional OpenRC information: OpenRC now
in Debian Experimental!"):
> OpenRC is now in Debian experimental! \o/
Good, thanks.
> I of course welcome anyone to try OpenRC and report bugs.
Can you point me to the relevant reference documentation ?
Thanks,
Ian.
Ian Jackson writes:
> | Choice of init system:
> |
> | 1. The default init(1) in jessie will be upstart.
> |
> | 2. Architectures which do not currently support upstart should try to
> |port it. If this is not achieved in time, those architectures may
> |continue to use sysvinit. [ Non-
On Fri, 2014-01-03 at 10:02 -0800, Nikolaus Rath wrote:
> Ian Jackson writes:
> > | 3. At least in jessie, unless a satisfactory compatibility approach is
> > |developed and deployed (see paragraph 10), packages must continue
> > |to provide sysvinit scripts. Lack of a sysvinit script (fo
Nikolaus Rath writes ("Bug#727708: init system discussion status"):
> As said elsewhere, I think there should be a paragraph about packages
> that depend on a specific init system for reasons other than service
> startup, e.g.
I agree with this.
> 4. The above criterium also extends to dependenci
Uoti Urpala wrote:
> Suppose an upstream releases a new daemon that is intended
> to be used with systemd using socket activation, and as such does not
> contain any code to do double-forking or open listening sockets. Would
> it be forbidden to package this daemon in Debian unless the maintainers
"Alexander E. Patrakov" writes:
> Uoti Urpala wrote:
>> Suppose an upstream releases a new daemon that is intended to be used
>> with systemd using socket activation, and as such does not contain any
>> code to do double-forking or open listening sockets. Would it be
>> forbidden to package this
Russ Allbery writes ("Bug#727708: init system discussion status"):
> The thrust of this seems right, but I dislike telling people what to do.
> Can we recast this in a way that avoids that problem? Maybe something
> like:
Sure. I borrowed your text and edited it slightly for clarity. I
also cha
Steve Langasek writes:
> The purpose of failsafe.conf is to ensure that services which have not
> been converted to the native format, but instead provide initscripts
> that are called upon reaching runlevel 2, are started at the right time
> - so that they aren't unreliable due to racing the net
Russ Allbery writes:
> However, that said, I believe the integration of systemd will actually
> be easier in the long run because upstart is rather... weird.
On that front, I also wanted to ask about:
https://bugs.launchpad.net/upstart/+bug/447654
If I'm understanding this bug correctly, i
Ian Jackson writes:
> Russ Allbery writes ("Bug#727708: init system discussion status"):
>> Another issue, which I did not address here but which we should
>> probably say something about, is that the init process 1 implementation
>> and the system used to run daemon configuration and startup job
Ian Jackson writes:
> Sure. I borrowed your text and edited it slightly for clarity. I also
> changed "upstart/systemd" to "upstart", for two reasons: one is that at
> this stage I'd prefer to try to maintain only one version of this text.
Yeah, that's fine. We can hammer out the details of o
On Fri, 2014-01-03 at 16:40 -0800, Russ Allbery wrote:
> Ian Jackson writes:
> > I've written a version of Niklaus's rule about dependencies:
>
> >Likewise, packages must not Depend on or Recommend (directly or
> >indirectly) a specific init(1). Violations of this are also an RC
> >b
Uoti Urpala writes:
> One case to consider is what should happen with GNOME if it requires
> interfaces that nobody has implemented for sysvinit.
The likelihood of this and possible impact is one of the things that I'm
checking on. I'd rather not have the argument if it turns out not to be
some
On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote:
> As said elsewhere, I think there should be a paragraph about packages
> that depend on a specific init system for reasons other than service
> startup, e.g.
>
> 4. The above criterium also extends to dependencies that are not related
Clint Adams writes:
> As loath as I am to participate in this discussion, I have to ask if
> your intent is to suddenly outlaw all the packages which depend on
> runit.
I don't think runit (or daemontools) are init systems. If you feel like
that may be ambiguous, we should say that explicitly.
Clint Adams wrote:
>On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote:
>> As said elsewhere, I think there should be a paragraph about packages
>> that depend on a specific init system for reasons other than service
>> startup, e.g.
>>
>> 4. The above criterium also extends to dependen
On Fri, Jan 3, 2014 at 7:17 PM, Russ Allbery wrote:
> Clint Adams writes:
>
> > As loath as I am to participate in this discussion, I have to ask if
> > your intent is to suddenly outlaw all the packages which depend on
> > runit.
>
> I don't think runit (or daemontools) are init systems. If yo
Josh Triplett writes:
> I think it'd be appropriate to allow dependencies on runit (or another
> package that contains an implementation of /sbin/init), as long as
> either the depending package doesn't depend on having /sbin/init be that
> init (which holds true for runit), *or* if an alternativ
Clint Adams writes:
> On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote:
>> As said elsewhere, I think there should be a paragraph about packages
>> that depend on a specific init system for reasons other than service
>> startup, e.g.
>>
>> 4. The above criterium also extends to depen
Russ Allbery writes:
>> I've written a version of Niklaus's rule about dependencies:
Just for the record, my suggestion was to include language that
regulates dependencies on the init system, but I do not have any
preferences whether they should be allowed or forbidden.
>>Likewise, packages
On Fri, 2014-01-03 at 20:26 -0800, Nikolaus Rath wrote:
> Clint Adams writes:
> > On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote:
> >> or alternatively
> >>
> >> 4. Packages may, however, depend on a specific init system (which may
> >>not be the default init) for features t
On 31 December 2013 12:32, Steve Langasek wrote:
> I agree that maintaining a systemd unit plus an upstart job is better than
> maintaining an init script. I just can't see any way through to a world
> where these will both actually be maintained (the testing problem),
> particularly if upstart u
Anthony Towns writes:
> I wonder if folks could clarify what status they expect secondary init
> systems to have in Debian?
My personal answer to this is that I truly don't know.
On one hand, we have four different init systems in Debian right now, plus
a fifth in experimental, and several of t
30 matches
Mail list logo
