Hi,
On Freitag, 17. Januar 2014, Lars Wirzenius wrote:
> Indeed. Early on in my original development of piuparts I realised
> that testing, in a chroot, code that starts arbitrary daemons is a bad
> idea in oh so many ways. I haven't followed piuparts development in
> recent years, so I don't know
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 script
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
> s
Steven Chamberlain dixit:
>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
I would like to express a preference for one init sys
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
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
Martin Pitt 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 system than jus
On 16/01/14 06:09, Martin Pitt wrote:
> There's no practical way to drop sysv of course, at least as long as
> we have non-Linux ports.
If maintainers are particularly keen to drop support for SysV, that
encourages porters to go with either OpenRC or a port of Upstart.
Then you could drop SysV su
On 15 January 2014 20:36, Martin Pitt 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 instead let main
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 t
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 equiv
Martin Pitt writes:
> Bdale Garbee [2014-01-13 13:57 -0700]:
>> Ian Jackson 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 rea
On 15/01/14 21:48, Russ Allbery wrote:
> If OpenRC proves to be of broad interest and becomes supported, at least
> at the non-default level, I doubt we would continue to support sysv
> without OpenRC for very long [...] the upgrade path from
> sysvinit only to sysvinit with OpenRC should be fairly
ni...@lysator.liu.se (Niels Möller) writes:
> (And it's going to be at least 4 init systems, not 3, right? systemd,
> upstart, sysv and openrc. With support for sysv possibly dropped after a
> few release cycles).
If OpenRC proves to be of broad interest and becomes supported, at least
at the non
Martin Pitt writes:
> I think that would be the worst possible (non-)decision that could be
> made. We already have more than enough bugs in Debian; officially
> trying to support 3 init systems is going to end up being a
> combinatorial explosion of testing and bugs, for no obvious benefit
> for
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 su
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 leg
>> 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 co
Bdale Garbee [2014-01-13 13:57 -0700]:
> Ian Jackson 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 tr
On Tue, Jan 14, 2014 at 06:32:48PM +, Ian Jackson wrote:
> It seems to me that the community for the particular init system ought
> to fix this. It's obviously not practical to ask the maintainer to
> debug each of these scripts.
And who is supposed to redirect the problem to the right
commun
Steve Langasek 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 positions with t
On Tue, Jan 14, 2014 at 11:31:09AM -0700, Bdale Garbee wrote:
> Adrian Bunk 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 for
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 after a few more such dependencies it would turn
> > > out that
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 after a few more such dependencies it would turn
> > out that systemd will be the only option available for virtually all
> > users -
Adrian Bunk writes ("Bug#727708: Bits from linux.conf.au"):
> I definitely expect that you have to reboot.
>
> The tricky part is how to reboot.
>
> With a naïve Breaks/Conflicts between the different init systems you
> would be calling the sysvinit reboot(8) with
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
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 alter
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
>>
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 ou
On Tue, Jan 14, 2014 at 06:05:47PM +, Ian Jackson wrote:
> Michael Stapelberg writes ("Bug#727708: Bits from linux.conf.au"):
> > Agreed. Effectively, this puts a lot of burden on individual maintainers
> > (and also on some external packagers) to test their packages
Adrian Bunk writes:
> There are at least three tricky areas:
>
> 1. init systems will have to cope with packages supplying init scripts
> in several formats they support.
This doesn't seem that tricky to me. If a package provides init
functionality in the preferred native format for a given in
Michael Stapelberg writes ("Bug#727708: Bits from linux.conf.au"):
> Adrian Bunk writes:
> > 1. init systems will have to cope with packages supplying init scripts
> > in several formats they support.
>
> Agreed. Effectively, this puts a lot of burden on indivi
Adrian Bunk writes ("Bug#727708: Bits from linux.conf.au"):
> There are at least three tricky areas:
>
> 1. init systems will have to cope with packages supplying init scripts
> in several formats they support.
Perhaps. I'm certainly not expecting to solve this pro
Hi Adrian,
Adrian Bunk writes:
> On Mon, Jan 13, 2014 at 01:57:29PM -0700, Bdale Garbee wrote:
>> Ian Jackson 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 th
Bdale Garbee writes ("Bug#727708: Bits from linux.conf.au"):
> Ian Jackson 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
On Mon, Jan 13, 2014 at 01:57:29PM -0700, Bdale Garbee wrote:
> Ian Jackson 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 hav
On 13/01/14 20:57, Bdale Garbee wrote:
> Ian Jackson 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
Ian Jackson 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 to define just what "support" m
Thorsten Glaser writes:
> 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. Th
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 initscript
Vincent Lefevre dixit:
>Well, the scripts may be started sequentially, but this doesn't mean
>that the daemons will be and always in the same order. And they don't,
>as shows in the following log:
That’s due to the (now default with sysv-rc) use of parallel boot
in combination with insserv. It us
On 13/01/14 13:48, Vincent Lefevre wrote:
> On 2014-01-13 13:15:07 +, Steven Chamberlain wrote:
>> In the slides[0] 13 to 15, he summarises init systems something like:
>> * SysV - simple, familiar and deterministic
>
> Deterministic?
Only the traditional SysV. Debian since squeeze uses star
On 2014-01-13 13:15:07 +, Steven Chamberlain wrote:
> In the slides[0] 13 to 15, he summarises init systems something like:
> * SysV - simple, familiar and deterministic
Deterministic?
Well, the scripts may be started sequentially, but this doesn't mean
that the daemons will be and always in
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
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 so
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:
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]
> http://mirror.linux.org.au/linux.conf.au/2014/Wednesday/71-Live_upgrading_many_thousands_of_servers_from_an_
There was a talk on January 08, 2014 at linux.conf.au Linux conference by Marc
Merlin, Google server
sysadmin and software engineer.
Quoting the description [1]:
> This talk will look at how we upgraded our ancient linux distribution on all
> the Google production
> servers to a more modern one
48 matches
Mail list logo
