On Thu, Dec 19, 2013 at 11:26:19PM +0100, Josselin Mouette wrote:
Le jeudi 19 décembre 2013 à 12:35 -0800, Steve Langasek a écrit :
The reasons for not upgrading to the current version of logind aren't to do
with any fragility of the existing glue code (the systemd-shim package), but
* Steve Langasek (vor...@debian.org) [131220 16:57]:
The design which claims this role for systemd-as-pid-1, and which does not
adequately address use cases of other existing cgroups consumers in the
ecosystem (lmctfy, lxc) is broken by design.
Having a single cgroup writer in userspace is
On Thu, Dec 19, 2013 at 09:43:05AM +0200, Adrian Bunk wrote:
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
Adrian Bunk b...@stusta.de writes:
Ubuntu is also using udev and logind without using systemd, so they are
and will continue to be available stand-alone.
Ubuntu is maintaining a variety of moderately fragile glue in order to
make this happen and currently can't upgrade to the current version
On Thu, Dec 19, 2013 at 09:53:01AM -0800, Russ Allbery wrote:
Adrian Bunk b...@stusta.de writes:
Ubuntu is also using udev and logind without using systemd, so they are
and will continue to be available stand-alone.
Ubuntu is maintaining a variety of moderately fragile glue in order to
Le jeudi 19 décembre 2013 à 12:35 -0800, Steve Langasek a écrit :
The reasons for not upgrading to the current version of logind aren't to do
with any fragility of the existing glue code (the systemd-shim package), but
because logind 205 has a new dependency on systemd as cgroup manager, which
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
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
On Tue, Dec 17, 2013 at 10:29:35AM -0800, Russ Allbery wrote:
Adrian Bunk b...@stusta.de writes:
this hits exactly the core of the problem:
The minimum supported Linux kernel version in glibc is currently 2.6.16,
released in 2006. And I'd trust glibc upstreamt that this requirement
Adrian Bunk b...@stusta.de writes:
The holding back upstream packages would only be true for Linux-only
software that additionally chooses to drop the non-kdbus codepaths.
As I already explained, software like glib2.0 and libdbus that supports
non-Linux kernels will anyway have to continue
On Tue, Dec 17, 2013 at 09:38:56PM +0200, Adrian Bunk wrote:
On Tue, Dec 17, 2013 at 10:29:35AM -0800, Russ Allbery wrote:
Adrian Bunk b...@stusta.de writes:
this hits exactly the core of the problem:
The minimum supported Linux kernel version in glibc is currently 2.6.16,
Kurt Roeckx k...@roeckx.be writes:
We release about every 2 years, but the kernel we have in wheezy was
already about 16 months old when wheezy was released. Jessie will
freeze in november 2014, so that the kernel will then be about 3 years
old. I'm going to assume that the release team is
Adrian Bunk b...@stusta.de writes:
this hits exactly the core of the problem:
The minimum supported Linux kernel version in glibc is currently 2.6.16,
released in 2006. And I'd trust glibc upstreamt that this requirement
won't suddenly be bumped to a quite recent version.
Is there any
Hi Russ,
Le mardi 17 décembre 2013 à 12:26 -0800, Russ Allbery a écrit :
Is there actually any implementation other than glib2.0 and libdbus that
would be affected by a switch to kdbus?
This is an interesting question. Josselin, is GNOME (for example) likely
to acquire a hard dependency
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 jessie+1.
Adrian But that is a risk, and it is a risk that is
Sam Hartman hartm...@debian.org writes:
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 avoid systemd entirely. It sounds like
we may be able to avoid systemd as pid 1
Hi Josselin,
reading through the systemd position statement [1], I ran into a
statement that is either incomplete or incorrect:
The upstart position statement [2] states:
-- snip --
systemd is hasty. ... While we are committed to having sane upgrade
paths and not depend on such kernel
35 matches
Mail list logo
