On Tue, Dec 17, 2013 at 06:02:50PM -0500, Sam Hartman wrote:
Adrian == Adrian Bunk b...@stusta.de writes:
Adrian Yes, it is speculation that other new features (or even
Adrian bugfixes) might appear in the kernel and might become
Adrian mandatory in systemd between jessie and
Hi Adrian,
Le mercredi 18 décembre 2013 à 13:34 +0200, Adrian Bunk a écrit :
That point you bring up is semi-orthogonal to the upgrade decision,
but it also brings up two important points that have to be considered:
1. What is the governance model of the systemd community?
This might be
On Wed, 2013-12-18 at 13:34 +0200, Adrian Bunk wrote:
On Tue, Dec 17, 2013 at 06:02:50PM -0500, Sam Hartman wrote:
I'm confused, when I hear you say that this risk is unique to the
systemd option and not shared by other options. I would understand that
statement if we thought we could
On Wed, Dec 18, 2013 at 03:10:19PM +0200, Uoti Urpala wrote:
In the kdbus case, systemd upstream already mentioned the possibility of
shipping kdbus as a new module for older kernels. More generally, you
can have solutions like applying some upgrades at boot rather than
trying to switch parts
Adrian, I'm frustrated when I read your message because you put words in
my mouth that I did not speak.
I never said that Debian should allow systemd to dictate policy for
multiple distributions nor did I say that Debian should allow one
upstream systemd maintainer to dictate decisions for Debian.
]] Uoti Urpala
In the kdbus case, systemd upstream already mentioned the possibility of
shipping kdbus as a new module for older kernels. More generally, you
can have solutions like applying some upgrades at boot rather than
trying to switch parts from under a fully live system. This does
On Wed, Dec 18, 2013 at 01:19:48PM +0100, Josselin Mouette wrote:
Hi Adrian,
Hi Josselin,
Le mercredi 18 décembre 2013 à 13:34 +0200, Adrian Bunk a écrit :
That point you bring up is semi-orthogonal to the upgrade decision,
but it also brings up two important points that have to be
On Wed, Dec 18, 2013 at 08:53:04AM -0500, Sam Hartman wrote:
Adrian, I'm frustrated when I read your message because you put words in
my mouth that I did not speak.
Hi Sam,
I never said that Debian should allow systemd to dictate policy for
multiple distributions nor did I say that Debian
On Wed, Dec 18, 2013 at 04:26:44PM +0200, Adrian Bunk wrote:
the *so far* is the worrisome part, considering how much power to
enforce policy whoever controls systemd has.
Switching to systemd also implies to trust that Lennart will do the
right things.
I am not in a position to judge
Hi,
Le mercredi 18 décembre 2013 à 16:26 +0200, Adrian Bunk a écrit :
We already seem to agree that the statement in the systemd position
statement that does not have any impact on the ability to upgrade
systems is not correct.
No, we do not. I have already explained why I believe the
Hi,
Adrian Bunk b...@stusta.de writes:
On Wed, Dec 18, 2013 at 01:19:48PM +0100, Josselin Mouette wrote:
And now you bring up the point that Debian should reconsider the
lenght of it's release cycles if systemd upstream decides to not
support upgrades between distribution releases as far
On Wed, Dec 18, 2013 at 03:10:19PM +0200, Uoti Urpala wrote:
On Wed, 2013-12-18 at 13:34 +0200, Adrian Bunk wrote:
...
When not using systemd as pid 1, that risk would be confined to the
parts of systemd Debian would be using (currently only udev).
I think you still misread the argument:
On Wed, Dec 18, 2013 at 04:10:19PM +0100, Ansgar Burchardt wrote:
Hi,
Adrian Bunk b...@stusta.de writes:
On Wed, Dec 18, 2013 at 01:19:48PM +0100, Josselin Mouette wrote:
And now you bring up the point that Debian should reconsider the
lenght of it's release cycles if systemd upstream
On Wed, Dec 18, 2013 at 03:50:33PM +0100, Josselin Mouette wrote:
Hi,
Hi Josselin,
...
I do not consider keeping an arbitrary number of packages at the wheezy
version an appropriate answer, regardless of the choice of init systems.
...
how many and which packages would have to be kept at the
]] Adrian Bunk
You're mixing two separate issues (or at least not clearly indicating
which one you're talking about). Systemd fully supports having a
separate /usr partition, and that is in no way deprecated AFAIK. What
has changed compared to old practice is that /usr needs to be
]] Josselin Mouette
It is possible to handle the situation with udev or with systemd,
because they do not make sense in a chroot environment, but they are the
exception, not the rule. And unless things go hectic, we *will* be able
to treat them normally and provide an upgrade path that
Adrian Bunk b...@stusta.de writes:
I was misreading that as referring to the headaches udev had caused in
the past for Debian upgrades, not that the systemd udev might be the
cause of future upgrade headaches.
But I do not buy this We already switched to systemd as upstream of
udev, so
Adrian Bunk b...@stusta.de writes:
[1] Personally, I am sceptical whether it is a good idea to switch to a
different init system for jessie. But I am not on a desperate rant
against systemd, and if something I bring up can be addressed that
is positive for me.
Just to give fair
Uoti Urpala writes (Bug#727708: systemd socket activation protocol rationale):
On Sat, 2013-12-14 at 21:45 +, Ian Jackson wrote:
Why do only some of the environment variables start SD_ ?
We have LISTEN_PID and LISTEN_FDS but SD_LISTEN_FDS_START.
You misread it: there is no environment
I wasn't able to find the reference manual for OpenRC. Perhaps I'm
just being dim. Could someone please point me at it ?
Thanks,
Ian.
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
On Sat, Dec 14, 2013 at 08:28:25PM +, Ian Jackson wrote:
Ian Jackson writes (upstart proposed policy in Debian):
Having read the docs there I have some apparently unanswered questions
about how the upstart proponents think we would use upstart in Debian.
I found policy 9.11.1 which I
Colin Watson cjwat...@debian.org writes:
For cases where simply running the daemon in the foreground is
insufficient (i.e. it's important to know more accurately about service
readiness), I personally prefer expect stop. While raising SIGSTOP
when they're ready isn't generally something
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Colin Watson writes (Re: Bug#727708: upstart proposed policy in Debian):
and it requires no particularly exciting code in the init daemon since
finding out about SIGSTOP already basically comes with the territory of
being pid 1.
It comes
Russ Allbery writes (Bug#727708: upstart proposed policy in Debian):
Is there a more complete explanation of this somewhere? The cookbook is
rather short on details.
It's documented in upstart's init(5) under expect stop.
I took a fairly quick look at the features provided by upstart and systemd
for starting and managing daemons, since that's the part that I feel the
most qualified to evaluate. I've been trying out different methods for
doing that for about 15 years and run a bunch of production systems with a
On Thu, Dec 19, 2013 at 01:19:10AM +, Colin Watson wrote:
On Sat, Dec 14, 2013 at 08:28:25PM +, Ian Jackson wrote:
Ian Jackson writes (upstart proposed policy in Debian):
Having read the docs there I have some apparently unanswered questions
about how the upstart proponents think
On Wed, Dec 18, 2013 at 02:44:03PM -0800, Russ Allbery wrote:
Adrian Bunk b...@stusta.de writes:
...
When not using systemd as pid 1, that risk would be confined to the
parts of systemd Debian would be using (currently only udev).
There appears to be near-unanimous agreement that Debian
On Wed, Dec 18, 2013 at 02:53:39PM -0800, Russ Allbery wrote:
Adrian Bunk b...@stusta.de writes:
[1] Personally, I am sceptical whether it is a good idea to switch to a
different init system for jessie. But I am not on a desperate rant
against systemd, and if something I bring up
]] Ian Jackson
systemd supports the non-forking daemon too. Only, instead of
raise(SIGSTOP) the daemon has to fetch an AF_UNIX socket name from an
environment variable, connect to it, and send a special message with
socket credentials attached.
Note that this is only if you need socket
29 matches
Mail list logo
