Hi,
On Donnerstag, 16. Januar 2014, Anthony Towns wrote:
it's not realistic for a porter to continously test startup
scripts for thousands of packages.
It's reasonable to semi-continuously test installation scripts for
thousands of packages -- that's what piuparts does, and we have
On Fri, Jan 17, 2014 at 12:05:22PM +0100, Holger Levsen wrote:
Hi,
On Donnerstag, 16. Januar 2014, Anthony Towns wrote:
it's not realistic for a porter to continously test startup
scripts for thousands of packages.
It's reasonable to semi-continuously test installation scripts for
On 15 January 2014 20:36, Martin Pitt mp...@debian.org wrote:
It's not realistic for a maintainer to continuously test three init
systems;
It's not realistic for a maintainer to continuously test against 13
architectures (including three different kernel trees) either. So we
don't do that and
Bdale Garbee [2014-01-16 8:44 -0700]:
But having more than $DEFAULT and
sysv just boils down to we can't make a decision.
I understand your point, but the more I learn about OpenRC the more
likely it seems to me that supporting it as an enhancement of sysvinit
makes sense as the other
Le jeudi 16 janvier 2014 à 08:44 -0700, Bdale Garbee a écrit :
I understand your point, but the more I learn about OpenRC the more
likely it seems to me that supporting it as an enhancement of sysvinit
makes sense as the other init system than just sysvinit alone.
This assumes that OpenRC can
Martin Pitt mp...@debian.org writes:
But having more than $DEFAULT and
sysv just boils down to we can't make a decision.
I understand your point, but the more I learn about OpenRC the more
likely it seems to me that supporting it as an enhancement of sysvinit
makes sense as the other init
Bdale Garbee [2014-01-13 13:57 -0700]:
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I'm coming round to the view that we should be planning to support
multiple systems indefinitely.
This has been my opinion all along. Various assertions that it's
somehow just too hard really
I'm coming round to the view that we should be planning to support
multiple systems indefinitely.
This has been my opinion all along. Various assertions that it's
somehow just too hard really haven't swayed me. The tricky bit, I
think, is to define just what support means in the context of
On Tue, Jan 14, 2014 at 11:19:38AM -0800, Steve Langasek wrote:
On Tue, Jan 14, 2014 at 08:03:50PM +0100, Josselin Mouette wrote:
Le mardi 14 janvier 2014 à 11:31 -0700, Bdale Garbee a écrit :
If dependencies like installing GNOME enforces systemd as init system
would be legal, then
On 15/01/14 21:01, Joerg Jaspert wrote:
Likewise I think one can forget the porters of an arch to do so.
[...]
As much as it may be hated, a clean decision this is it, the rest is
officially not supported [...]
If the decision were something like that, and only systemd were
officially
Hey Yves-Alexis,
Yves-Alexis Perez [2014-01-15 22:17 +0100]:
Now, as far as I understand it, PolicyKit/ConsoleKit are unmaintained,
and the recommended alternative is to use logind.
To clarify, ConsoleKit has been deprecated for a while, and logind is
the official successor (and roughly
Niels Möller [2014-01-15 22:34 +0100]:
Users should not select a non-default init system lightly. I think it's
going to be a bit like using the non-default kfreebsd or hurd kernel.
It's not for the average user who wants as much software as possible to
work as well as possible. It's for the
On Mon, Jan 13, 2014 at 01:57:29PM -0700, Bdale Garbee wrote:
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I'm coming round to the view that we should be planning to support
multiple systems indefinitely.
This has been my opinion all along. Various assertions that it's
somehow
Sergey B Kirpichev writes (Re: Bug#727708: Bits from linux.conf.au):
On Tue, Jan 14, 2014 at 06:05:47PM +, Ian Jackson wrote:
I would expect the community for that init system to do the work. So
the burden on maintainers ought to be minimal. All they ought to be
required to do is ship
Bdale Garbee writes (Bug#727708: Bits from linux.conf.au):
That's a great question. I suspect most of the effort in thinking about
init system transitions so far has gone in to figuring out how to replace
sysvinit. But if we're truly going to support alternatives, ensuring we
have a robust
Hello.
On 01/14/2014 10:32 PM, Ian Jackson wrote:
Sergey B Kirpichev writes (Re: Bug#727708: Bits from linux.conf.au):
On Tue, Jan 14, 2014 at 06:05:47PM +, Ian Jackson wrote:
I would expect the community for that init system to do the work. So
the burden on maintainers ought
On Tue, Jan 14, 2014 at 06:03:33PM +, Ian Jackson wrote:
Adrian Bunk writes (Bug#727708: Bits from linux.conf.au):
...
3. Switching init systems after installation.
Assume I am currently using systemd.
What is supposed to happen when I do apt-get install sysvinit-core?
I think
On Tue, Jan 14, 2014 at 11:31:09AM -0700, Bdale Garbee wrote:
Adrian Bunk b...@stusta.de writes:
...
If dependencies like installing GNOME enforces systemd as init system
would be legal, then after a few more such dependencies it would turn
out that systemd will be the only option available
Steve Langasek vor...@debian.org writes:
And all such statements are mere parroting of systemd upstream
propaganda. The interfaces that desktops require do not dictate an init
system.
Please extend to your fellow Debian developers the courtesy of assuming
that they arrive at their personal
Hello.
On 01/13/2014 03:57 PM, Алексей Шилин wrote:
In his talk [2] at 13:50 Marc briefly touched the init system choice
question. Perhaps it's worth taking
into account.
[2]
On Mon, Jan 13, 2014 at 12:15:02PM +, Thorsten Glaser wrote:
Алексей Шилин dixit:
In his talk [2] at 13:50 Marc briefly touched the init system choice
question.
Can you please provide a transcript, for those among us who
do not watch any video?
This talk in article format:
On 13/01/14 12:15, Thorsten Glaser wrote:
Алексей Шилин dixit:
In his talk [2] at 13:50 Marc briefly touched the init system choice
question.
Can you please provide a transcript, for those among us who
do not watch any video?
In the slides[0] 13 to 15, he summarises init systems something
Steven Chamberlain writes (Bug#727708: Bits from linux.conf.au):
Then he gives a preference for Debian's own insserv and startpar. It
allows for boot order to be fixed (after running insserv once, the same
/etc/rc2.d/Sxx numbering may be rsync'd out to many machines). startpar
allows
Steven Chamberlain dixit:
Actually, even if they forked in the same order every time, they might
not be *ready* in the same order. That would be the rationale for
readiness protocols and other features of the more complex init systems.
Strong disagree. This actually is a bug in the initscripts
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I'm coming round to the view that we should be planning to support
multiple systems indefinitely.
This has been my opinion all along. Various assertions that it's
somehow just too hard really haven't swayed me. The tricky bit, I
think, is
On 13/01/14 20:57, Bdale Garbee wrote:
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I'm coming round to the view that we should be planning to support
multiple systems indefinitely.
This has been my opinion all along. Various assertions that it's
somehow just too hard really haven't
26 matches
Mail list logo
