Tollef Fog Heen writes ("Bug#727708: loose ends for init system decision"):
> Ian Jackson:
> > So, firstly, I would say that all packages must, in jessie at least,
> > continue to support sysvinit. Russ (from the other side of the
> > upstart/systemd fence) agree
]] Ian Jackson
> Nikolaus Rath writes ("Bug#727708: loose ends for init system decision"):
> > I think there is one additional questions that will probably need to be
> > decided by the tc but hasn't really been discussed yet:
> >
> > Will packages tha
On Thu, Jan 2, 2014 at 11:46 AM, Josselin Mouette wrote:
> Le jeudi 02 janvier 2014 à 18:30 +, Ian Jackson a écrit :
> > I would hope that we can standardise on a single API to the system's
> > single cgroup writer.
>
> I have already explained why this is not going to happen. The cgroups
> A
Josselin Mouette writes ("Bug#727708: loose ends for init system decision"):
> Le jeudi 02 janvier 2014 à 18:30 +, Ian Jackson a écrit :
> > I would hope that we can standardise on a single API to the system's
> > single cgroup writer.
>
> I have alread
Le jeudi 02 janvier 2014 à 18:30 +, Ian Jackson a écrit :
> I would hope that we can standardise on a single API to the system's
> single cgroup writer.
I have already explained why this is not going to happen. The cgroups
API in systemd is already part of the core systemd interface and subje
On 01/02/2014 10:30 AM, Ian Jackson wrote:
> Nikolaus Rath writes ("Re: Bug#727708: loose ends for init system decision"):
>> For example, a hypothetical future program to interactively adjust
>> program cgroups cannot be sysvinit compatible in any meaningful sense,
>&
Nikolaus Rath writes ("Re: Bug#727708: loose ends for init system decision"):
> For example, a hypothetical future program to interactively adjust
> program cgroups cannot be sysvinit compatible in any meaningful sense,
> because it does not need to be supervised, started,
On 01/02/2014 10:20 AM, Ian Jackson wrote:
> Nikolaus Rath writes ("Bug#727708: loose ends for init system decision"):
>> I think there is one additional questions that will probably need to be
>> decided by the tc but hasn't really been discussed yet:
>>
>&
Nikolaus Rath writes ("Bug#727708: loose ends for init system decision"):
> I think there is one additional questions that will probably need to be
> decided by the tc but hasn't really been discussed yet:
>
> Will packages that explicity depend on a (non-default)
Russ Allbery writes:
> 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 separat
On 30 Dec 2013, at 18:47, Russ Allbery wrote:
> However, I think it's the best available approach that balances our ideals
> as a project against the opportunities offered by a new init system. This
> approach does permit full use of new init system features for jessie
> except for eliminating /e
On Tue, Dec 31, 2013 at 10:18:08PM -0800, Russ Allbery wrote:
> For upstart readiness, obviously one needs some sort of explicit flag or
> trigger to enable the raise(SIGSTOP) behavior, since that will otherwise
> cause rather obvious problems in getting the daemon to work outside of
> upstart. I
Ian Jackson writes:
> Well, no. I think that even if we select upstart as the default, we
> should enable the systemd community to provide as complete a set of
> integration in Debian as they care to put the work in for.
> That translates directly to an expectation that the maintainer of any
>
Okay, let's see how replying to a mail on my phone while in flight mode
goes. Apologies in advance for formatting, quoting and vocabulary issues.
On Dec 31, 2013 4:48 AM, "Russ Allbery" wrote:
> 2. Impact of Multiple Init Systems
> Obviously, the ideal situation for project-wide integration and
On Mon, Dec 30, 2013 at 10:24 PM, Steve Langasek wrote:
> 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
]] Ian Jackson
> So I think we need to say what we regard as "reasonable" patches, in
> advance. As the Debian maintainer for uservd (for example), am I
> entitled to decline to incorporate systemd integration into my package
> on the grounds that the patch involves additional build- and runtime
Michael Stapelberg writes:
> That being said, I just checked and realized the package is not
> available on non-linux. I’ll look into that now, since intuitively there
> is no reason for this.
Thank you, Michael. That would indeed make things much easier. I think
Ian is being excessively drama
Hi Ian,
Ian Jackson writes:
>> > This is particularly the case for build-dependencies on an avowedly and
>> > intentionally non-portable program. Of course this can be made
>> > conditional, but this is IMO too fiddly.
>>
>> Adding [linux-any] to the Build-Depends line is not too fiddly, and if
Russ Allbery writes ("Bug#727708: loose ends for init system decision"):
> Ian Jackson writes:
> > For me it's a different proposition to suppose that _every_ daemon
> > should bring in these kind of dependencies.
>
> It's only going to be *every* d
Ian Jackson writes:
> Russ Allbery writes ("Bug#727708: loose ends for init system decision"):
>> These requirements, on the other hand, I find completely baffling.
>> This approach seems completely contrary to Debian best practices. Our
>> standard practic
Michael Gilbert writes ("Bug#727708: loose ends for init system decision"):
> On Mon, Dec 30, 2013 at 7:16 PM, Vincent Bernat wrote:
> > Unfortunately, being the best init is the not only the matter of its
> > maintainers. A good integration implies to modify some packages
Russ Allbery writes ("Bug#727708: loose ends for init system decision"):
> Ian Jackson writes:
> > - avoid extra build-dependencies (eg on libsystemd)
> > - avoid extra runtime dependencies (eg on deb-systemd-helper)
>
> These requirements, on the other h
Steve Langasek writes:
> When it comes to technology choices, you win some and you lose some. If
> upstart wins, I will be happy. If systemd wins, I will also be happy,
> because it's long overdue that Debian *make a decision*; and for all
> that there are aspects of systemd that make me uncomf
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
On Mon, Dec 30, 2013 at 7:20 PM, Russ Allbery wrote:
> Michael Gilbert 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 opinio
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
Michael Gilbert 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 section 6.1.2
❦ 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 init is the not only the matter of its
maintainers. A goo
On Mon, Dec 30, 2013 at 5:51 PM, Russ Allbery wrote:
> Michael Gilbert 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 fai
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 cul
Michael Gilbert 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
opinions. That means t
Tollef Fog Heen 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 «upstart
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,
]] 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 «system
Ian Jackson 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 earlier.
> I think that pat
Ian Jackson 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
>&g
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
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 r
We have been asked to decide the default init system for jessie. As I
have just said, my conclusion is that we should choose upstart.
However, we also need to decide whether we intend to allow users to
choose otherwise. So we need to say what we expect of package
maintainers in terms of support
39 matches
Mail list logo
