On Tue, Nov 04, 2014 at 01:38:24AM +, Jonathan de Boyne Pollard wrote:
> Zbigniew Jędrzejewski-Szmek:
> >Distribution packages have been almost all converted to systemd
> > services, with a handful of less-used-packages remaining [1].
>
> Jóhann B Guðmundsson, the erstwhile feature owner for
Zbigniew Jędrzejewski-Szmek:
Distribution packages have been almost all converted to systemd
> services, with a handful of less-used-packages remaining [1].
Jóhann B Guðmundsson, the erstwhile feature owner for Fedora's System 5
rc to systemd units conversion project, states that the conversi
Josh Triplett writes:
> Russ Allbery wrote:
>> There are a ton, but because Debian architectures encode choice of
>> kernel, they're represented in the archive as packages that are not
>> available for kFreeBSD or Hurd, or only available for kFreeBSD, or only
>> available for Hurd.
> That said,
The Wanderer writes:
> On 11/02/2014 at 07:58 PM, Russ Allbery wrote:
>> That's because the point of systemd-shim is to provide the services
>> that logind requires without running systemd as PID 1, so that packages
>> can then depend on logind without requiring systemd be PID 1. That
>> didn't
(Responding quickly to only the part I think I can address well on short
notice, without needing to spend a long time thinking it over.)
On 11/02/2014 at 07:58 PM, Russ Allbery wrote:
> The Wanderer writes:
>> systemd-shim 8.2 and 7.1 do not list a dependency on systemd, or
>> appear to invoke
[I agree wholeheartedly with Russ's points regarding systemd and logind.
One tangential response to a different point:]
Russ Allbery wrote:
> There are a ton, but because Debian architectures encode choice of kernel,
> they're represented in the archive as packages that are not available for
> kFr
The Wanderer writes:
> Is it? I thought part of the problem is that there are packages whose
> upstream supports (or at least enables) compiling with / without
> integration to functionality provided by systemd, and which are provided
> in Debian only as compiled with that functionality enabled,
On Fri, Oct 31, 2014 at 06:07:20PM +0900, Tristan Van Berkom wrote:
> Is systemd the problem or is the GNOME Desktop Environment[0] ?
Could you maybe address this within GNOME first instead of on Debian?
Going to Debian because you have a concern within GNOME seems rather
counter productive. First
On Thu, Oct 30, 2014 at 11:02:22PM +0100, Svante Signell wrote:
> I should not have mentioned any company at` all, sorry :(
That would be the first step, yes.
--
WBR, wRAR
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas
On Fri, 2014-10-31 at 09:37 +0530, Rustom Mody wrote:
> On Thu, 30 Oct 2014 16:54:33 +0900 Tristan van Berkom wrote:
> > [Disclaimer: I am not a debian developer myself and probably do not have
> > the right to vote here, I am however a long time contributor and
> > maintainer in GNOME who has be
Russ Allbery writes:
> Every time I look at that web page, I find another egregious error.
> This time, I just noticed that their minimal PID 1 implementation that
> they think is the be-all and end-all of PID 1 ends with a call to
> execve. I'm going to be laughing about that for the rest of th
Svante Signell writes:
> PID 1 should be as small as possible, see a proposed implementation in:
> http://ewontfix.com/14/
That web page still cracks me up. Not only does the author have no idea
how systemd works and makes multiple claims that are simply false, they
have no idea how *sysvinit*
On Thu, 30 Oct 2014 16:54:33 +0900 Tristan van Berkom wrote:
> [Disclaimer: I am not a debian developer myself and probably do not have
> the right to vote here, I am however a long time contributor and
> maintainer in GNOME who has been watching this thread and I feel I have
> a responsibility
Hi,
Svante Signell:
>
> Why do you cut out the most important part of that message? You all
> trigged on the first part, I should not have mentioned any company at
> all, sorry :(
>
Oh well, if you insist:
>>> The more important that Debian does not drop support for sysvinit then,
>>> until alt
On Thu, Oct 30, 2014 at 01:24:55PM -0500, Jordan Metzmeier wrote:
> On Thu, Oct 30, 2014 at 12:32 PM, Jonas Smedegaard wrote:
> >
> > That does not sound to me as Fedora _only_ supporting systemd, or am I
> > missing something?
> >
>
> It looks like Fedora 20 still has a sysvinit package, but it
> Svante Signell:
> >
> > > And OpenSUSE also dropped support:
> >
> > Of course RHEL and Fedora dropped sysvinit support, they are Redhat
> > derived. Can anybody guess where systemd is developed?
> >
> Well, OpenSUSE (and several others who have by now switched to systemd)
> are not. So?
Why
On Thu, Oct 30, 2014 at 12:32 PM, Jonas Smedegaard wrote:
>
> That does not sound to me as Fedora _only_ supporting systemd, or am I
> missing something?
>
It looks like Fedora 20 still has a sysvinit package, but it won't
exist in the next release[1]. Upstart is also retired[2]. I would
consider
Quoting Josh Triplett (2014-10-30 15:04:04)
> Aigars Mahinovs wrote:
>> Fedora actually is not that decisive, as far as I read here -
>> https://fedorahosted.org/fpc/ticket/243
>
> That ticket turned down the suggested policy of "packages MUST NOT
> support sysvinit". That doesn't mean "packages
Hi,
Svante Signell:
>
> > And OpenSUSE also dropped support:
>
> Of course RHEL and Fedora dropped sysvinit support, they are Redhat
> derived. Can anybody guess where systemd is devloped?
>
Well, OpenSUSE (and several others who have by now switched to systemd)
are not. So?
Please stop the co
On Thu, Oct 30, 2014 at 11:12 PM, Svante Signell wrote:
> Can anybody guess where systemd is devloped?
No need to guess when they have git logs:
http://cgit.freedesktop.org/systemd/systemd/log/
I recognise people from these distros in the git logs: debian mageia
redhat archlinux ubuntu tizen su
> >
> > ArchLinux is clearly dropping sysvinit. RHEL documentation also seems
> > to imply that Sysvinit and Upstart are both dropped in 7+.
> >
> > Fedora actually is not that decisive, as far as I read here -
> > https://fedorahosted.org/fpc/ticket/243
>
> It wasn't 19 months ago, but is pett
On Thu, Oct 30, 2014 at 09:46:44AM +, Adam D. Barratt wrote:
> fwiw, as this seems to be a commonish error - you mean "could not
> care less". People who could care less by definition do care.
It's an en_US thing, I think.
http://public.wsu.edu/~brians/errors/couldcare.html
--
To UNSUBSCRI
At Thu, 30 Oct 2014 14:32:29 +0200,
Aigars Mahinovs wrote:
>
> On 30 October 2014 12:24, Cameron Stewart wrote:
> > On Thu, Oct 30, 2014 at 9:06 PM, Aigars Mahinovs wrote:
> >> Have other distros switched to _only_ supporting systemd? Changing the
> >> default is not the same. This is not a rhet
Aigars Mahinovs wrote:
> Fedora actually is not that decisive, as far as I read here -
> https://fedorahosted.org/fpc/ticket/243
That ticket turned down the suggested policy of "packages MUST NOT
support sysvinit". That doesn't mean "packages MUST support sysvinit",
or "packages MUST NOT depend o
On 30 October 2014 12:24, Cameron Stewart wrote:
> On Thu, Oct 30, 2014 at 9:06 PM, Aigars Mahinovs wrote:
>> Have other distros switched to _only_ supporting systemd? Changing the
>> default is not the same. This is not a rhetorical question - it would
>> actually be useful to know if other dist
On Thu, Oct 30, 2014 at 9:06 PM, Aigars Mahinovs wrote:
> Have other distros switched to _only_ supporting systemd? Changing the
> default is not the same. This is not a rhetorical question - it would
> actually be useful to know if other distros have actually already
> abandoned support for non-s
On 30 October 2014 11:43, Matthias Urlichs wrote:
> Arguments by popularity are not going to sway anybody here. Otherwise I
> could shut you up with a simple "most other distros have switched and are
> mostly-happy with it". :-P
Have other distros switched to _only_ supporting systemd? Changing t
Matthias Urlichs wrote:
Hi,
Florian Lohoff:
There are tons of people who think that all the above functionality does
not belong to a init systemd or ecosystem.
There are also tons of people who could care less, as long as it gets the
job done.
Then there are tons of people who are _very_ hap
On 2014-10-30 9:43, Matthias Urlichs wrote:
Hi,
Florian Lohoff:
There are tons of people who think that all the above functionality
does
not belong to a init systemd or ecosystem.
There are also tons of people who could care less, as long as it gets
the
job done.
fwiw, as this seems to be
Hi,
Florian Lohoff:
> There are tons of people who think that all the above functionality does
> not belong to a init systemd or ecosystem.
>
There are also tons of people who could care less, as long as it gets the
job done.
Then there are tons of people who are _very_ happy about the fact that
Hi,
On Wed, Oct 29, 2014 at 02:51:57PM +, Marco d'Itri wrote:
> ijack...@chiark.greenend.org.uk wrote:
>
> >I don't want to be having this conversation again in a year's time,
> > its replacements for syslog,
> You are not required to replace your syslog daemon, and indeed the
> Debian syst
On Thu, Oct 30, 2014 at 10:32:00AM +0200, Aigars Mahinovs wrote:
> This discussion can end for good in two ways:
> * Debian declares that user choice of init systems is important and
> applications must respect that;
> * Debian declares that only systemd is supported;
The currently GRs appear to b
Hi,
On Wed, Oct 29, 2014 at 11:10:59AM +0100, Josselin Mouette wrote:
> Which is why sticking to the lowest common denominator among init
> systems is the worst thing we could do as a project.
I would like to stick with lowest common denominator.
Everyone who likes the feature bloat of any softw
On 30 October 2014 04:35, Marco d'Itri wrote:
> ijack...@chiark.greenend.org.uk wrote:
>
>>If my GR fails I expect a series of bitter rearguard battles over
>>individual systemd dependencies.
> This looks like a great way to encourage people to make systemd
> mandatory just to be done with this on
Ian Jackson writes:
> That's not the problem. The problem is the possibility of packages wich
> requires systemd's syslog replacement, its cron replacement, or its ntpd
> replacement.
This isn't a reason for a GR. This is a reason for Policy saying that
packages must not do that and must inste
ijack...@chiark.greenend.org.uk wrote:
>If my GR fails I expect a series of bitter rearguard battles over
>individual systemd dependencies.
This looks like a great way to encourage people to make systemd
mandatory just to be done with this once and for all... :-)
>That's not the problem. The pro
Ian Jackson wrote:
> Marco d'Itri writes ("Re: Legitimate exercise of our constitutional
> decision-making processes [Was, Re: Tentative summary of the amendments]"):
> > ijack...@chiark.greenend.org.uk wrote:
> > >I don't want to be having this convers
On Wed, Oct 29, 2014, at 20:03, Matthias Urlichs wrote:
> And if that happens with journald, I fully expect that somebody will step
> up and provide a replacement implementation (either of the daemon, or the
> underpinnings it needs) that works without systemd-as-pid1. Just like
> systemd-shim.
Sp
Hi,
Ian Jackson:
> If my GR passes we will only have to have this conversation if those
> who are outvoted do not respect the project's collective decision.
>
As opposed to us having this discussion _now_ because some people
apparently cannot accept the fact that Debian works quite well
without i
On 2014-10-29 16:13, Ian Jackson wrote:
Marco d'Itri writes ("Re: Legitimate exercise of our constitutional
decision-making processes [Was, Re: Tentative summary of the
amendments]"):
ijack...@chiark.greenend.org.uk wrote:
>I don't want to be having this conversation
Marco d'Itri writes ("Re: Legitimate exercise of our constitutional
decision-making processes [Was, Re: Tentative summary of the amendments]"):
> ijack...@chiark.greenend.org.uk wrote:
> >I don't want to be having this conversation again in a year's time,
>
&
On Mittwoch, 29. Oktober 2014, Ian Jackson wrote:
> In the battle between those upstreams and Debian contributors [...]
please, don't mention the war.
signature.asc
Description: This is a digitally signed message part.
On Wed, Oct 29, 2014 at 12:27:40PM +, Ian Jackson wrote:
> Neil McGovern writes ("Re: Legitimate exercise of our constitutional
> decision-making processes [Was, Re: Tentative summary of the amendments]"):
> > As far as I'm aware, we don't actually say that any
ijack...@chiark.greenend.org.uk wrote:
>I don't want to be having this conversation again in a year's time,
And still, I am ready to bet that we will...
>with those upstreams and their like-minded Debian contributors saying
>things like `it is too late now; the world has moved on'.
It is *already
On Wed, Oct 29, 2014 at 02:16:14PM +0200, Aigars Mahinovs wrote:
> On 29 October 2014 13:40, Neil McGovern wrote:
> >> * if we go the MTA/sh route, then we define lowest common denominator
> >> interface of an init system and only init systems providing that
> >> (possibly with a systemd-shim) can
Neil McGovern writes ("Re: Legitimate exercise of our constitutional
decision-making processes [Was, Re: Tentative summary of the amendments]"):
> As far as I'm aware, we don't actually say that anywhere. Applications can
> only /rely/ on those interfaces, but it&#
Philip Hands writes ("Re: Legitimate exercise of our constitutional
decision-making processes [Was, Re: Tentative summary of the amendments]"):
> I thought you said that your GR (i.e. option 1) was effectively a NOP
> for Jessie (that's certainly how I read the text of y
On 29 October 2014 13:40, Neil McGovern wrote:
>> * if we go the MTA/sh route, then we define lowest common denominator
>> interface of an init system and only init systems providing that
>> (possibly with a systemd-shim) can be init systems in the archive and
>> also applications can only depend
On Tue, Oct 28, 2014 at 06:31:43PM +0200, Aigars Mahinovs wrote:
> 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 req
Aigars Mahinovs writes ("Re: Legitimate exercise of our constitutional
decision-making processes [Was, Re: Tentative summary of the amendments]"):
> This is an interesting insight. It also can be used to identify
> possible solutions for the current issue:
>
> * if we go the
Hi,
Le mercredi 29 octobre 2014 à 09:22 +, Philip Hands a écrit :
> Of course, for the likes of Gnome, voting for Option 1 really will have
> an immediate effect, which will be to completely demotivate our Gnome
> maintainers, since this would be a vote against them.
>
> I think Debian withou
[cross-post to -project dropped]
Hi Ian,
Ian Jackson writes:
> 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]"
(Dropping -project)
Le mardi, 28 octobre 2014, 17.26:32 Ian Jackson a écrit :
> Thanks to Steve for his perceptive and well-reasoned article.
>
> Steve Langasek writes:
> > There are also a lot of Debian users who are afraid of what the
> > future holds for an OS that they love very much; and the
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 hold
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
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
(I wonder about the extent to which this remains on-topic... I didn't
hesitate about my previous post, since it was relatively brief and
addressed what I thought was an important and relevant single point, but
this is considerably longer and gets rather farther afield.)
On 10/27/2014 at 11:54 PM,
The Wanderer writes:
> Just as a note, one difference here is that there is support in the
> archive and package-distribution mechanisms for having multiple versions
> of a package for different architectures or (I think?) kernels, so that
> you can build a version with some optional features for
On 10/27/2014 at 10:29 PM, Anthony Towns wrote:
> On 28 October 2014 02:36, Steve Langasek wrote:
>>> It's clear that many who support systemd balk at the idea they
>>> might not be allowed to leverage systemd-specific features in
>>> Debian.
>
> I'm not sure I've seen people seriously proposin
-project dropped -- no need to spam multiple lists, and -vote seems
like the right place for this topic to me.
On 28 October 2014 02:36, Steve Langasek wrote:
> On Fri, Oct 24, 2014 at 01:32:36PM +, Anthony Towns wrote:
>> On Fri, Oct 24, 2014 at 01:48:33PM +0300, Aigars Mahinovs wrote:
>> >
Steve Langasek wrote:
> On Fri, Oct 24, 2014 at 01:32:36PM +, Anthony Towns wrote:
> > If you were literally beating people with a stick for not testing their
> > packages with other init systems, that would certainly be compulsion, no?
> > Using policy and RC bugs as a metaphorical stick to be
On Fri, Oct 24, 2014 at 01:32:36PM +, Anthony Towns wrote:
> On Fri, Oct 24, 2014 at 01:48:33PM +0300, Aigars Mahinovs wrote:
> > On 24 October 2014 13:15, Anthony Towns wrote:
> > > On Fri, Oct 24, 2014 at 12:57:49PM +0300, Aigars Mahinovs wrote:
> > >> No developer in that chain was compelle
On Oct 26, Flavius Bindea wrote:
> if systemd is goinging to be the default I'll switch to another distrib.
systemd is already the default and it will still be the default no
matter the outcome of this GR, which is about something else.
> maybe to a fork.
Cool. Debian encourages forks.
--
cia
if systemd is goinging to be the default I'll switch to another distrib.
maybe to a fork.
2014-10-25 23:38 GMT+02:00 Marco d'Itri :
> svante.sign...@gmail.com wrote:
>
> >This is incredible, 90+ postings are from the pro systemd people. Are
> >you afraid of something? Where do the other side of
On Sat, Oct 25, 2014 at 11:52:32AM -0400, Miles Fidelman wrote:
> Olav Vitters wrote:
> >3. That we tried to blackmail someone
> if it looks like a duck, and quacks like a duck..
> >4. That it is about sysvinit scripts
> Again, of course it is.
> >If you cannot, it seems you just performed
svante.sign...@gmail.com wrote:
>This is incredible, 90+ postings are from the pro systemd people. Are
>you afraid of something? Where do the other side of view speak up. Seems
Indeed, it looks like that systemd users are seriously underrepresented
in these threads:
https://qa.debian.org/popcon-g
Svante Signell wrote:
Hi,
This is incredible, 90+ postings are from the pro systemd people. Are
you afraid of something? Where do the other side of view speak up. Seems
like the same thing happening again when the default init system was
chosen, the more loudly the more strength in affecting peo
Hi,
This is incredible, 90+ postings are from the pro systemd people. Are
you afraid of something? Where do the other side of view speak up. Seems
like the same thing happening again when the default init system was
chosen, the more loudly the more strength in affecting peoples opinions.
Keep on,
Olav Vitters wrote:
On Fri, Oct 24, 2014 at 09:56:33AM -0400, Miles Fidelman wrote:
All this talk about what upstream developers will and won't do.
Seems to me that they've been writing sysvinit scripts for years;
systemd support ADDS work. It's only the GNOME developers who are
being rather vo
On Sat, Oct 25, 2014 at 03:21:51PM +0200, Jonas Smedegaard wrote:
> Quoting Josh Triplett (2014-10-25 11:52:28)
> > Jonas Smedegaard wrote:
> >> Quoting Josh Triplett (2014-10-24 16:27:27)
> >>> Aigars Mahinovs wrote:
> On 24 October 2014 13:33, Ansgar Burchardt
> wrote:
> > I don't
Hi,
j...@joshtriplett.org:
> Personally, I'd actually love to see a port of systemd (a *complete*
> port of systemd) to be capable of running in system mode without being
> PID 1.
Why would you need to port it?
You can do that today quite easily; just say "systemd --system".
I have no idea what
Hi,
Josh Triplett:
> There's a reason that systemd has had a meteoric adoption rate: it
> provides a huge number of features people not only want, but have wanted
> for years.
>
Or didn't even know they wanted. Or simply didn't have *time* to implement
a workaround for. The integrated logging whi
Quoting Josh Triplett (2014-10-25 11:52:28)
> [Please CC me on replies; I'm not subscribed to -vote, so for mails not
> CCed to me, I end up responding via the archives and manually quoting
> via copy/paste.]
>
> Jonas Smedegaard wrote:
>> Quoting Josh Triplett (2014-10-24 16:27:27)
>>> Aigars Mahi
Le vendredi 24 octobre 2014 à 14:47 +0200, Josselin Mouette a écrit :
> There
> have been, are and will be people with different requirements that
> systemd does not and will not satisfy.
>
> Which requirements are not satisfied by systemd? I’m pretty sure the
> upstream sy
On Fri, Oct 24, 2014 at 09:56:33AM -0400, Miles Fidelman wrote:
> All this talk about what upstream developers will and won't do.
> Seems to me that they've been writing sysvinit scripts for years;
> systemd support ADDS work. It's only the GNOME developers who are
> being rather vocal about not s
On Sat, Oct 25, 2014 at 12:51:04AM +0300, Aigars Mahinovs wrote:
> On 24 October 2014 23:16, wrote:
> > I'd personally be interested in your non-devil's-advocate reasons for
> > caring, because
> > those seem likely to be solvable.
>
> I, personally, love the init part of systemd - the part tha
[Please CC me on replies; I'm not subscribed to -vote, so for mails not
CCed to me, I end up responding via the archives and manually quoting
via copy/paste.]
Jonas Smedegaard wrote:
> Quoting Josh Triplett (2014-10-24 16:27:27)
> > Aigars Mahinovs wrote:
> >> On 24 October 2014 13:33, Ansgar Burc
On 24 October 2014 23:16, wrote:
> I'd personally be interested in your non-devil's-advocate reasons for caring,
> because
> those seem likely to be solvable.
I, personally, love the init part of systemd - the part that starts
services (either on startup or on events).
>> and there is no
>> ne
Ian Jackson writes:
d> Jonas Smedegaard writes ("Re: Tentative summary of the amendments"):
>> Quoting Nikolaus Rath (2014-10-22 05:09:18)
>> > I believe Ian's intended reading is that a package that depends on
>> > uselessd | systemd (but does not wor
On Fri, Oct 24, 2014 at 08:31:22PM +0300, Aigars Mahinovs wrote:
> First of all, Josh, thank you for the long and reasoned replies. I do
> hope this back-and-forth is useful for others as well in the context
> of this decision, that is why I am still keeping the debian-vote list
> in the CC.
Likew
Quoting Josh Triplett (2014-10-24 16:27:27)
> Aigars Mahinovs wrote:
>> On 24 October 2014 13:33, Ansgar Burchardt wrote:
>>> I don't like some software too, but am sometimes required to use it
>>> without an alternative. Can I demand that I can use packages without
>>> said software? Like deman
First of all, Josh, thank you for the long and reasoned replies. I do
hope this back-and-forth is useful for others as well in the context
of this decision, that is why I am still keeping the debian-vote list
in the CC.
On 24 October 2014 19:18, Josh Triplett wrote:
> Aigars Mahinovs wrote:
>> Fo
Aigars Mahinovs wrote:
> On 24 October 2014 17:14, Josh Triplett wrote:
> >> The key difference is that until this year all packages worked on all
> >> init systems (as in you could start any service or application with
> >> any init system as PID 1, even with "init=/bin/sh").
> >
> > Until recent
On 24 October 2014 17:27, Josh Triplett wrote:
>> In any case, this is uncharted territory, because (to my knowledge)
>> until systemd started integrating system level services into init
>> system itself, applications never depended on particular APIs of init
>> systems.
>
> Sure they did. Applic
On 24 October 2014 17:14, Josh Triplett wrote:
>> The key difference is that until this year all packages worked on all
>> init systems (as in you could start any service or application with
>> any init system as PID 1, even with "init=/bin/sh").
>
> Until recently, it was a painful endeavor to be
Aigars Mahinovs wrote:
> On 24 October 2014 13:33, Ansgar Burchardt wrote:
> > So, if P has a hard dependency on systemd-as-pid1, why do you want to
> > take P away from me? Because people not liking systemd are more
> > important than people not caring about it or even being okay with it?
>
> It
On Fri, Oct 24, 2014 at 03:50:48PM +0300, Aigars Mahinovs wrote:
> On 24 October 2014 15:40, Josh Triplett wrote:
> > What makes the systemd case so drastically different that those who care
> > about alternative init systems cannot follow the same procedure?
>
> The key difference is that until
Aigars Mahinovs wrote:
On 24 October 2014 12:35, Ansgar Burchardt wrote:
In fact, they want to require that if P supports only A (and not A|B)
that the maintainers of P have to patch P to make it support B. In the
good old days[tm] it would be the responsibility of the people wanting
to use B t
On Fri, 24 Oct 2014 10:21:01 +0200, Holger Levsen said:
> Hi Uoti, thanks for your summmary of the situation.
> On Donnerstag, 23. Oktober 2014, Uoti Urpala wrote:
>> In another mail, Ian said that his interpretation is that the init
>> system would not only have to be packaged in Debian, but in
On Fri, Oct 24, 2014 at 04:02:24PM +0300, Aigars Mahinovs wrote:
> That is not what is actually required. It is sufficient to handle the
> situation when such functionality is not available. That is inside the
So in case functionality is not available in more than one init system,
upstream cannot
On Fri, Oct 24, 2014 at 01:48:33PM +0300, Aigars Mahinovs wrote:
> On 24 October 2014 13:15, Anthony Towns wrote:
> > On Fri, Oct 24, 2014 at 12:57:49PM +0300, Aigars Mahinovs wrote:
> >> No developer in that chain was compelled
> >> to run this under other init systems.
> > Well, yeah:
> > "1. No
In the entire systemd conversation, there's hardly been any discussion
about non-desktop stuff. Or has there ? I may have missed. I've mentioned
this previously in some of the bug reports, maybe do here too.
How are other packagers taking care of it ? There are a lot of server
daemons that need so
On 24 October 2014 15:33, Olav Vitters wrote:
> On Fri, Oct 24, 2014 at 01:48:33PM +0300, Aigars Mahinovs wrote:
>> No, but we set up requirements that their work must meet before it can
>> enter archive or may end up in a release. That is what the whole of
>> Debian Policy is about.
>
> That is t
On Fri, Oct 24, 2014 at 01:48:33PM +0300, Aigars Mahinovs wrote:
> No, but we set up requirements that their work must meet before it can
> enter archive or may end up in a release. That is what the whole of
> Debian Policy is about.
That is things within the package itself. This is about doing ex
On 24 October 2014 15:40, Josh Triplett wrote:
> What makes the systemd case so drastically different that those who care
> about alternative init systems cannot follow the same procedure?
The key difference is that until this year all packages worked on all
init systems (as in you could start an
1 - 100 of 134 matches
Mail list logo
