Steve, thanks for writing up your note.
I strongly agree that Ian's resolution is legitimate. It's not a abuse
of process, it's reasonably to bring forward.
I also think Charles's amendment is legitimate in the same sense: to say
that we as a community do not choose to act as a community in this
Josselin Mouette writes:
> Russ Allbery wrote:
> If GNOME supported being built without those features, yes, it's
> fairly straightforward. I probably overstated it by saying it's
> trivial, but I don't think it would be that hard. But that's
> from the *packag
Russ Allbery wrote:
If GNOME supported being built without those features, yes, it's fairly
straightforward. I probably overstated it by saying it's trivial, but I
don't think it would be that hard. But that's from the *packaging*
perspective, which is the part o
On 10/28/2014 at 12:20 PM, Russ Allbery wrote:
> The Wanderer writes:
>
>> What I'm thinking of is cases where upstream has decided to depend
>> on functionality that is provided by one init system but not by
>> others, without graceful runtime fallback - compile-time choices,
>> essentially, wh
Thanks to Steve for his perceptive and well-reasoned article.
Steve Langasek writes ("Legitimate exercise of our constitutional
decision-making processes [Was, Re: Tentative summary of the amendments]"):
> There are also a lot of Debian users who are afraid of what the future holds
> for an OS th
On 28 October 2014 18:20, Russ Allbery wrote:
> With all of those facilities, we've taken different approaches; with the
> mail transport agent, for example, we've defined an interface that all
> mail transport agents are required to implement, and MTA implementations
> that don't implement that i
The Wanderer writes:
> What I'm thinking of is cases where upstream has decided to depend on
> functionality that is provided by one init system but not by others,
> without graceful runtime fallback - compile-time choices, essentially,
> where functionality is omitted if the init system is not p
Aigars Mahinovs wrote:
> On 28 October 2014 12:12, Josselin Mouette wrote:
> > This is nice and all, but how to you tell such a “sub-init” which
> > services have been already started and which services it has to start
> > itself?
>
> The point of a sub-init would be to start one specific service.
Dear all!
I'm trying to run multiple init systems in parallel.
First step: run systemd with PID!=1.
It does not run out of the box: hacking systemd is needed [2] [3]
Nevertheless I got a system up and running - but it's still degraded:
4 S root 1 0 0 80 0 - 1052 - 11:28
On 28 October 2014 12:12, Josselin Mouette wrote:
> This is nice and all, but how to you tell such a “sub-init” which
> services have been already started and which services it has to start
> itself?
The point of a sub-init would be to start one specific service.
Basically the idea would be that
On Sun, Oct 26, 2014 at 07:15:15PM +, Gerrit Pape wrote:
> On Sat, Oct 25, 2014 at 08:58:49AM -0700, Josh Triplett wrote:
> > Matthias Urlichs wrote:
> > > j...@joshtriplett.org:
> > > > Personally, I'd actually love to see a port of systemd (a *complete*
> > > > port of systemd) to be capable
Richard Hartmann wrote:
Has anyone actually tested the viability of running systemd in
non-PID-1 mode?
If yes, does this work and would it continue to work?
If yes, is there any hard commitment from upstream in this regard?
Assuming the answers to all of
Dear all,
as probably most others, I am deeply unhappy with the current state of affairs.
All sides have compelling arguments, which means, to me, that it would
be a benefit to all involved if there was a commonly accepted
solution.
Maybe there's still room for rough consensus[1], however unlikel
On 28 October 2014 04:29, Anthony Towns wrote:
> The corresponding question for services versus init systems would be:
>
> - package "foo" has a .service file upstream, but no init script
> - Alice packages foo, doesn't write an init script, and uploads it to
> unstable
> - it's automatically
14 matches
Mail list logo
