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
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 j...@debian.org writes:
It shouldn’t come as a surprise that it is hard for developers to
respect the TC’s decisions when we see disrespectful
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
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
[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
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 ijack...@chiark.greenend.org.uk 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
On Fri, 2014-01-03 at 10:02 -0800, Nikolaus Rath wrote:
Ian Jackson ijack...@chiark.greenend.org.uk 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
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 dependencies
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 changed
Steve Langasek vor...@debian.org 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
Russ Allbery r...@debian.org 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
Ian Jackson ijack...@chiark.greenend.org.uk 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
Uoti Urpala uoti.urp...@pp1.inet.fi 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
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 cl...@debian.org 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
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 dependencies that
On Fri, Jan 3, 2014 at 7:17 PM, Russ Allbery r...@debian.org wrote:
Clint Adams cl...@debian.org 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)
Clint Adams cl...@debian.org 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
On 31 December 2013 12:32, Steve Langasek vor...@debian.org 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),
Anthony Towns a...@erisian.com.au 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
22 matches
Mail list logo
