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 work with sysvinit) would be allowed
>> > by hi
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
Hi Lucas,
On Thu, Oct 23, 2014 at 09:07:42AM +0200, Lucas Nussbaum wrote:
> Oh, yes, sure. But is this point still valid? My perception is that the
> current set of amendments is good enough. But if you were planning to
> propose one yourself and haven't had time to do it yet, I am of course
> fin
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
Aigars Mahinovs wrote:
So you want to force everyone to use systemd
No, I want every package to work with the default init system. Those who
only use packages that work with another init system, can use it.
(by breaking enough
software so that Debian becomes unusable w
On Fri, Oct 24, 2014 at 05:40:28AM -0700, Josh Triplett wrote:
> Ansgar Burchardt wrote:
My apologies, that should have been:
> Aigars Mahinovs wrote:
(The web archives on lists.debian.org have reply-to links, but those
links don't include quoted mail text as the BTS links do; I copy-pasted
the
Ansgar Burchardt wrote:
> The root of the problem is coming from upstream not caring about
> alternative init systems. To take the logind case as an example - each
> of the dependencies from GDM to systemd make perfect sense in
> isolation. However, the end result (was) that GDM only worked with
>
On Fri, Oct 24, 2014 at 12:57:49PM +0300, Aigars Mahinovs wrote:
> The root of the problem is coming from upstream not caring about
> alternative init systems. To take the logind case as an example - each
> of the dependencies from GDM to systemd make perfect sense in
> isolation. However, the end
Hi,
On 10/24/2014 02:02 PM, Josselin Mouette wrote:
> 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
On 24 October 2014 15:02, Josselin Mouette wrote:
> However these choices heavily impact our users who (for whatever
> reasons) want or need to use another init system.
>
> No, they don’t. “Wanting another init system” is not a functional need.
> It is a tantrum from people who are
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 responsibi
On 24 October 2014 13:33, Ansgar Burchardt wrote:
> But instead we should take away packages that depend on a features only
> provided by a specific init system (for whatever reason)? Do you think
> we serve users better by taking away options from them?
Sometimes - yes, especially in the long te
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. Nothing in this constitution imposes an obligation on anyone to do
> work f
Hi,
Aigars Mahinovs writes:
> 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 wan
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. Nothing in this constitution imposes an obligation on anyone to do
work for the Project."
Compelling developers isn't something that
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 to submit patches t
Hi,
Aigars Mahinovs writes:
> This is the same requirement as with regular dependencies. If you want
> into next release, then all your dependencies must be there.
No, it's not. In the past your package P could depend on A|B and
everything was fine if either A or B was there. If B was broken and
On 24 October 2014 12:12, Holger Levsen wrote:
> On Freitag, 24. Oktober 2014, Aigars Mahinovs wrote:
>> This is the same requirement as with regular dependencies. If you want
>> into next release, then all your dependencies must be there. If you
>> want to be supporting two init systems in next r
On Freitag, 24. Oktober 2014, Holger Levsen wrote:
> "If you package GNOME, just must also maintain KDE, cause I think GNOME
> is/will $foo." - what?
... _you_ must also maintain KDE...
signature.asc
Description: This is a digitally signed message part.
Hi Aigars,
(this reply is not really directed at you..)
On Freitag, 24. Oktober 2014, Aigars Mahinovs wrote:
> This is the same requirement as with regular dependencies. If you want
> into next release, then all your dependencies must be there. If you
> want to be supporting two init systems in n
On 24 October 2014 11:21, Holger Levsen wrote:
> 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 test
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 testing and
> not RC buggy.
yeah, I found this interpration a
37 matches
Mail list logo
