]] Russ Allbery
First, thanks to both you and Ian for the quite comprehensive
write-ups.
If the package later changes the flags in some orthogonal way, it's
easy for the system to miss that change. This is something that,
under systemd, will probably require development of new tools to warn
On Sun, Dec 29, 2013 at 10:05:17PM +0100, Tollef Fog Heen wrote:
It would, however, be nice if this were more clearly stated, since the
guidance to the author of the unit file about what dependencies one should
or should not explicitly add is a bit sparse. In particular, I wonder if
there
[Started drafting this before Ian forked the bug; sending to both bug
reports now]
On Fri, Dec 20, 2013 at 03:41:55PM -0800, Russ Allbery wrote:
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Russ Allbery writes:
I'd like to see both of them support systemd's method, since it's
Hi Ian,
On Sat, Dec 14, 2013 at 12:31:57PM +, Ian Jackson wrote:
I have some questions about these. Forgive me if I could just have
looked up the answers:
Are they enabled by default in jessie/sid ?
(If the answer is no then feel free not to answer the rest...)
No :)
Using upstart
Steve Langasek vor...@debian.org writes:
On Mon, Dec 02, 2013 at 02:48:52PM -0800, Russ Allbery wrote:
I have never seen a gratuitous incompatibility caused by this. Do you
have any examples?
I would argue that every single result returned by 'ls -l /usr/sbin/
/usr/bin|grep /bin',
Steve Langasek writes (Bug#727708: systemd and upstart, a view from a daemon
Debian maintainer):
I also think that the extensive maintainer script changes required for any
upstart-using package are quite deplorable (whether or not they're wrapped
in a helper script + debhelper snippet). [...]
Tollef Fog Heen writes (Bug#733452: init system daemon readiness protocol):
Ian Jackson:
I conclude therefore that we should design another simple protocol -
preferably, a variation on one of the existing ones - and have (at
least) both Debian's systemd and Debian's upstart implement it.
Russ Allbery r...@debian.org writes:
* Red Hat adopted upstart but never did a wholescale conversion, and then
abandoned upstart in favor of systemd. Obviously, one should not put
too much weight on this; Red Hat is a commercial company that has a
wealth of reasons for its actions that
(Sorry, 2nd copy here because I missed up the change of To field in
the previous one.)
cameron writes (Re: Bug#733452: init system daemon readiness protocol):
I was curious: why should SOCK_STREAM be used instead of SOCK_DGRAM in
your proposed protocol?
SOCK_DGRAM sockets do not offer
Steve Langasek writes (Re: Bug#727708: upstart user jobs):
On Sat, Dec 14, 2013 at 12:31:57PM +, Ian Jackson wrote:
I have some questions about these. Forgive me if I could just have
looked up the answers:
Are they enabled by default in jessie/sid ?
(If the answer is no then feel
]] Ian Jackson
Tollef Fog Heen writes (Bug#727708: init system other points, and
conclusion):
Ian Jackson:
This is exacerbated by the fact that systemd's Debian maintainers are
(IMO) much too deferential to upstream.
That's because the bits of systemd you've asked to change isn't
On Mon, 30 Dec 2013 09:05:57 -0800, Russ Allbery wrote:
By comparison, upstart is effectively used only by Ubuntu, [...]
Both of these statements are incorrect.
I'm sure that somewhere in the many vast threads that we've had over the
init system, someone pointed out to me that Google's
Steve Langasek writes (Bug#727708: systemd-shim uploaded to NEW):
So I repeat here my request that the systemd maintainers make a suitable
split of the systemd binary package, so that systemd-shim will be
coinstallable with the systemd-provided implementations of the other dbus
services.
Is
On Mon, 30 Dec 2013, Ian Jackson wrote:
The only alternative I see is for systemd-shim to declare a
Replaces: against systemd without a Conflicts,
This would be quite wrong; Replaces is not supposed to be used like
that (but you apparently know that).
How do the systemd maintainers
This message is about a transition plan for an init system replacement and
about how to handle portability to our non-Linux ports. I'm keeping the
same subject as Ian's message on the same basic topics and attaching it to
the same thread, but this is more of a separate writeup than a reply.
I'll
Russ Allbery writes (Bug#727708: init system other points, and conclusion):
We seem to be at the point of the process where at least those of us who
did early investigation are stating conclusions. I think I have enough
information to state mine, so will attempt to do so here.
Thanks.
Russ Allbery writes (Bug#727708: loose ends for init system decision):
1. Role of Non-Linux Ports in Debian
I agree with most of this.
2. Impact of Multiple Init Systems
I don't want to do a blow-by-blow quote/rebuttal of this.
3. systemd and upstart As Multiple Systems
..
I therefore
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Russ Allbery writes (Bug#727708: loose ends for init system decision):
6. Debian's non-Linux ports should either use the same init system as
Debian's Linux ports or agree on an init system that they're both going
to use. The porting
On Mon, Dec 30, 2013 at 9:43 AM, Tollef Fog Heen tfh...@err.no wrote:
If this is not required by systemd, why is it done by sd_notify ?
It's not.
You obviously did not read the code. It is. Here is a G+ convo with
Lennart I had:
As a sender you only have to set SCM_CREDENTIALS
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Russ Allbery writes (Bug#727708: init system other points, and conclusion):
First, other choices besides systemd and upstart.
I agree with your comments here; it appears you've investigated OpenRC
in more detail than I have but I'm happy to
The documentation says what sd_notify() does, not what the minimum
requirements are. The documentation should be clarified IMO, but
Lennart does not seem to want to do so (even though he already typed up
a paragraph about it on G+).
On Mon, Dec 30, 2013 at 9:02 AM, Ian Jackson
On Mon, Dec 30, 2013 at 05:35:49PM +, Ian Jackson wrote:
Steve Langasek writes (Re: Bug#727708: upstart user jobs):
On Sat, Dec 14, 2013 at 12:31:57PM +, Ian Jackson wrote:
I have some questions about these. Forgive me if I could just have
looked up the answers:
Are they
]] Ian Jackson
Steve Langasek writes (Bug#727708: systemd-shim uploaded to NEW):
So I repeat here my request that the systemd maintainers make a suitable
split of the systemd binary package, so that systemd-shim will be
coinstallable with the systemd-provided implementations of the other
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I think we should give package maintainers some guidance on what kinds
of upstart or systemd patches should be accepted. Without this, it's
likely we'll find ourselves adjudicating disputes that ought to have
been settled in principle much
On Mon, Dec 30, 2013 at 06:29:10PM +, Ian Jackson wrote:
Steve Langasek writes (Bug#727708: systemd-shim uploaded to NEW):
So I repeat here my request that the systemd maintainers make a suitable
split of the systemd binary package, so that systemd-shim will be
coinstallable with the
On Mon, Dec 30, 2013 at 11:56 AM, Russ Allbery r...@debian.org wrote:
The latest that I have seen on this porting effort is here:
http://blog.surgut.co.uk/2013/11/libnih-upstart-dependency-ported-to.html
I asked previously on this bug if someone had later news. Do you have
more information
Tollef Fog Heen wrote:
Initially, by waiting for the ctte to come to a conclusion. If that is
that systemd should be the default init system I think we should solve
the problem by not solving it. If the decision is that another init
system should be solved, I'm probably going to solve it by
]] cameron
On Mon, Dec 30, 2013 at 9:43 AM, Tollef Fog Heen tfh...@err.no wrote:
If this is not required by systemd, why is it done by sd_notify ?
It's not.
You obviously did not read the code. It is. Here is a G+ convo with
Lennart I had:
As a sender you only have to set
This message contains some supplemental information to go with my primary
writeup, and some profound thanks for the people involved in this
investigation.
I apologize for the huge volume of mail, and I know it's going to take a
while to digest. I appreciate people's willingness to read all these
On Mon, Dec 30, 2013 at 1:35 PM, Tollef Fog Heen tfh...@err.no wrote:
]] cameron
On Mon, Dec 30, 2013 at 9:43 AM, Tollef Fog Heen tfh...@err.no
wrote:
If this is not required by systemd, why is it done by sd_notify
?
It's not.
You obviously did not read the code. It is. Here is
]] Russ Allbery
Given that, I don't believe a Technical Committee choice of a default init
system is going to make either the systemd or the upstart maintainers want
to stop maintaining their packages.
Given what you're basically deciding between is «upstart + castrated
systemd» or «systemd»
On Mon, Dec 30, 2013 at 1:47 PM, Russ Allbery wrote:
4. Conclusions
I previously argued that much of the benefit of a new init system comes
from when we can stop maintaining init scripts. I still believe that, but
after thinking more about the cultural and project issues at stake here,
as
Tollef Fog Heen tfh...@err.no writes:
]] Russ Allbery
Given that, I don't believe a Technical Committee choice of a default
init system is going to make either the systemd or the upstart
maintainers want to stop maintaining their packages.
Given what you're basically deciding between is
Michael Gilbert mgilb...@debian.org writes:
Doesn't a TC mandate on the default init system in some sense violate
Debian's spirit of meritocracy?
I believe that we have enough information to make an informed choice
already, and that the sides are fairly well-defined and hardened in their
Hi,
(Sorry if I am duplicating a point that was already made.
These threads are huge, and don't fit entirely into my memory.)
Ian Jackson wrote (30 Dec 2013 18:58:37 GMT) :
Russ Allbery writes (Bug#727708: init system other points, and conclusion):
Rather, we're talking about whether or not to
On 12/30/2013 04:31 PM, Michael Gilbert wrote:
On Mon, Dec 30, 2013 at 1:47 PM, Russ Allbery wrote:
4. Conclusions
I previously argued that much of the benefit of a new init system comes
from when we can stop maintaining init scripts. I still believe that, but
after thinking more about the
On Mon, Dec 30, 2013 at 11:56:33AM -0800, Russ Allbery wrote:
Rather, we're talking about whether or not to swap out a core component
of an existing integrated ecosystem with a component that we like
better.
Unless you are proposing to make systemd mandatory for all Debian
On Mon, Dec 30, 2013 at 01:44:10PM -0800, Russ Allbery wrote:
* systemd provides really nice command-line tools for understanding the
state of the system and the relationships between the unit files. I
don't believe upstart has an equivalent of systemctl list-dependencies,
for example.
On Mon, Dec 30, 2013 at 01:03:48PM -0800, Steve Langasek wrote:
This would be quite wrong; Replaces is not supposed to be used like
that (but you apparently know that).
Yes. Raphaël rightly points out that dpkg-divert can be used for this; if
necessary, that's what I'll do.
But I still
On Mon, 2013-12-30 at 18:58 +, Ian Jackson wrote:
Also, I get the impression me that the integration of much of this
functionality into the systemd source package has been done for
political rather than technical reasons. Indeed to the extent that
there is a problematically tight
Steve Langasek vor...@debian.org writes:
From comments made by various GNOME upstream developers on this, I think
they are being suitably cautious about avoiding scope creep where the
systemd dependencies are concerned. So in what sense are the GNOME and
KDE requirements not already being
❦ 30 décembre 2013 23:31 CET, Michael Gilbert mgilb...@debian.org :
Doing something like this, the best init system can win based truly on
merit (if/when the work gets done), rather than as a fuzzy upfront
judgement call.
Unfortunately, being the best init is the not only the matter of its
Michael Gilbert mgilb...@debian.org writes:
On Mon, Dec 30, 2013 at 5:51 PM, Russ Allbery wrote:
I believe that we have enough information to make an informed choice
already, and that the sides are fairly well-defined and hardened in
their opinions. That means that this dispute falls under
On Mon, Dec 30, 2013 at 7:16 PM, Vincent Bernat wrote:
❦ 30 décembre 2013 23:31 CET, Michael Gilbert :
Doing something like this, the best init system can win based truly on
merit (if/when the work gets done), rather than as a fuzzy upfront
judgement call.
Unfortunately, being the best
On Tue, Dec 31, 2013 at 12:27:28AM -0008, cameron wrote:
systemd lists logind as non-reimplementable, and that was pretty
much proven when Ubuntu tried to reimplement it and ended up
reimplementing or pulling in a ton of systemd anyway.
All this proves is that Ubuntu developers have the good
On Mon, Dec 30, 2013 at 7:20 PM, Russ Allbery wrote:
Michael Gilbert mgilb...@debian.org writes:
On Mon, Dec 30, 2013 at 5:51 PM, Russ Allbery wrote:
I believe that we have enough information to make an informed choice
already, and that the sides are fairly well-defined and hardened in
their
I see that the LWN commentariat already has my decision selected in
advance, so I might as well write up some more detailed thoughts before
any other words are put into my mouth!
Choice of default
-
Firstly, I've tried to keep my employer affiliation out of this as much
as
On Mon, Dec 30, 2013 at 04:04:05PM -0800, Russ Allbery wrote:
My belief, and again I welcome concrete reasons why I'm not correct, is
that adopting upstart poses a similar risk for the Hurd port as adopting
systemd, and I care just as much about the Hurd port as kFreeBSD. And
while kFreeBSD
Thanks for this write-up, Colin. This was very interesting to me,
particularly in the concrete examples of where you've felt like systemd
has stepped into areas that will pose integration problems for us. This
is something that I've seen referred to in the abstract frequently, but
without a lot
On Mon, Dec 30, 2013 at 08:12:19PM -0500, Michael Gilbert wrote:
Part of my goal in writing up that plan was, as you
say, to try to provide a means for people who are committed to one system
or the other to continue to work on what they're passionate about even if
it's not chosen as the
Colin Watson wrote:
(Now, I've been working with Upstart's model for years, and it's now a
pretty fundamental way of how I think of system operation; so if people
who are new to *both* models rather than partisans of one side or the
other consistently tell me that the systemd model is easier
On Mon, Dec 30, 2013 at 04:04:05PM -0800, Russ Allbery wrote:
Steve Langasek vor...@debian.org writes:
From comments made by various GNOME upstream developers on this, I think
they are being suitably cautious about avoiding scope creep where the
systemd dependencies are concerned. So in
On Tue, 2013-12-31 at 02:55 +, Colin Watson wrote:
My main concerns with systemd relate to its broad scope regarding units
it provides for system initialisation tasks currently performed by other
packages, and the potential for that to interfere with past and future
work elsewhere in
On Mon, Dec 30, 2013 at 7:17 PM, Colin Watson cjwat...@debian.org
wrote:
On Mon, Dec 30, 2013 at 04:04:05PM -0800, Russ Allbery wrote:
My belief, and again I welcome concrete reasons why I'm not
correct, is
that adopting upstart poses a similar risk for the Hurd port as
adopting
systemd,
On Mon, Dec 30, 2013 at 6:55 PM, Colin Watson cjwat...@debian.org
wrote:
The ptrace arrangements used for expect fork and expect daemon
have
been rather flaky in practice, especially when Upstart jobs are
written
by people not experts in doing so, and they are an obstacle to
portability.
Steve Langasek wrote:
On Mon, Dec 30, 2013 at 04:04:05PM -0800, Russ Allbery wrote:
Please recall the context here: this whole aside started with an objection
to my contention that adopting upstart requires disassembly and redoing of
an integration that we would otherwise not have to
On Mon, Dec 30, 2013 at 07:26:23PM -0800, Russ Allbery wrote:
(Now, I've been working with Upstart's model for years, and it's now a
pretty fundamental way of how I think of system operation; so if people
who are new to *both* models rather than partisans of one side or the
other
Steve Langasek vor...@debian.org writes:
Upstart (as implemented in Ubuntu) restores this guarantee (with
provisions for failsafe booting in the case of a wrong network config),
and it takes advantage of upstart's capability of sending arbitrary
signals to do so. I can see how one could
Oh, sorry, I forgot to respond to this part.
Steve Langasek vor...@debian.org writes:
Of course if we were writing all our services according to best
practices, we wouldn't have to worry about this, as the service would
just handle this gracefully (or maybe hand the complexity off to the
On Mon, Dec 30, 2013 at 10:04:09PM -0800, Russ Allbery wrote:
Oh, sorry, I forgot to respond to this part.
Steve Langasek vor...@debian.org writes:
Of course if we were writing all our services according to best
practices, we wouldn't have to worry about this, as the service would
just
On Mon, Dec 30, 2013 at 09:58:07PM -0800, Josh Triplett wrote:
But in the real world, we have a lot of services that we just want to start
in runlevel 2 and be able to trust that the network and disk are sorted.
This is the classic guarantee that sysvinit gave us pre-udev, but it's
fallen
Steve Langasek vor...@debian.org writes:
On Sun, Dec 29, 2013 at 01:43:59PM -0800, Nikolaus Rath wrote:
I'm a bit surprised that you mention this only now, after Russ'
extensive mail. Could you tell us if there are there other components in
systemd that you think are similarly flawed,
Why
62 matches
Mail list logo
