]] Adrian Bunk
I already gave my hypothetical udev gets a hard dependency on systemd
as init system worst case.
To make the worst case even worse, assume a new upstream version of
systemd with this change gets released 2 weeks before the jessie freeze,
and gets uploaded into unstable
Adrian Bunk b...@stusta.de writes:
On Sat, Jan 18, 2014 at 08:49:48PM -0800, Russ Allbery wrote:
Adrian Bunk b...@stusta.de writes:
The problem is different - with systemd there is a fast process going
on where frequently-used configurations stop working without systemd.
Are you only
On Sun, Jan 19, 2014 at 11:00:01AM +0100, Tollef Fog Heen wrote:
]] Adrian Bunk
I already gave my hypothetical udev gets a hard dependency on systemd
as init system worst case.
To make the worst case even worse, assume a new upstream version of
systemd with this change gets released
On Sun, Jan 19, 2014 at 02:59:01AM -0800, Russ Allbery wrote:
Adrian Bunk b...@stusta.de writes:
On Sat, Jan 18, 2014 at 08:49:48PM -0800, Russ Allbery wrote:
...
No, I am not assuming bad faith.
But there will be cases where the goals like
1. give users of systemd under Linux the best
On 19/01/14 12:20, Adrian Bunk wrote:
Why do you want Debian to support multiple init systems in the first place?
I think because:
* whichever is chosen as default, there will be some users who
specifically don't like it, or specifically want something else
(including major consumers like
]] Adrian Bunk
On Sun, Jan 19, 2014 at 11:00:01AM +0100, Tollef Fog Heen wrote:
]] Adrian Bunk
I already gave my hypothetical udev gets a hard dependency on systemd
as init system worst case.
To make the worst case even worse, assume a new upstream version of
systemd with
On Sun, Jan 19, 2014 at 04:05:08PM +0100, Tollef Fog Heen wrote:
]] Adrian Bunk
...
If I was a systemd maintainer I would consider it a reasonable option to
rather upload a new version of systemd that adds such a dependency to
udev instead of shipping an ancient systemd in the next
I think you and I have some fundamental disagreements about how this
decision-making process should work, so I'm not sure that we're going to
reach some satisfactory conclusion to this discussion. But I'll take
another try at this from another angle and see if it helps.
Adrian Bunk
* Russ Allbery (r...@debian.org) [140118 05:15]:
Steve Langasek vor...@debian.org writes:
I don't believe we need to know the answer to these questions to know
that Ian's requirement is a correct one. If we are saying that packages
cannot drop their sysvinit scripts in jessie in order to
On Fri, Jan 17, 2014 at 08:13:30PM -0800, Russ Allbery wrote:
...
I believe it is reasonable to allow GNOME to require systemd as the init
system if that's the only way to get a working logind with the software
that we release with jessie,
Why does logind actually have to be a hard dependency
On Fri, Jan 17, 2014 at 11:29 AM, Thorsten Glaser wrote:
Moritz Muehlenhoff dixit:
FreeBSD upstream isn't a desktop OS and never will be, there're just too
many deficiencies (e.g. lack of dbus
Eh, excuse me! It’s obviously possible to run a desktop without dbus!
In fact, this is a feature, in
Adrian Bunk b...@stusta.de writes:
Why does logind actually have to be a hard dependency for GNOME in
jessie?
If it doesn't, then it's not an issue. But it seemed like at least a
possibility given upstream GNOME direction.
What is your general position on what dependencies on a specific
On Sat, Jan 18, 2014 at 09:45:35AM -0800, Russ Allbery wrote:
...
If software that people want to package for Debian is deeply entangled in
one init system (that is supported in Debian), for good or for ill,
regardless of what one might think of the decisions made by upstream that
created that
Adrian Bunk b...@stusta.de writes:
On Sat, Jan 18, 2014 at 09:45:35AM -0800, Russ Allbery wrote:
If software that people want to package for Debian is deeply entangled
in one init system (that is supported in Debian), for good or for ill,
regardless of what one might think of the decisions
On Fri, Jan 17, 2014 at 12:51:48PM +, Ian Jackson wrote:
Adrian Bunk writes (Re: Bug#727708: Init system resolution open questions):
(Only as a PM since I am repeating myself.)
Thanks for your mail. I think it deserves wider consideration.
One question you should consider adding
On Sat, Jan 18, 2014 at 11:22:06AM -0800, Russ Allbery wrote:
Adrian Bunk b...@stusta.de writes:
...
We are in full agreement on that.
And my point on top of that is that if the CTTE decsion would be that
Debian should support multiple init systems, but it does not set a
policy limiting
Adrian Bunk b...@stusta.de writes:
On Sat, Jan 18, 2014 at 11:22:06AM -0800, Russ Allbery wrote:
There is a natural process here, where rarely-used configurations
slowly stop working and people eventually decide not to bother to keep
them working and move on to other things. Eventually, they
On Sat, Jan 18, 2014 at 08:49:48PM -0800, Russ Allbery wrote:
Adrian Bunk b...@stusta.de writes:
On Sat, Jan 18, 2014 at 11:22:06AM -0800, Russ Allbery wrote:
There is a natural process here, where rarely-used configurations
slowly stop working and people eventually decide not to bother
Tollef Fog Heen writes (Bug#727708: Init system resolution open questions):
[Ian Jackson]:
As I mentioned on IRC, I think we need to get some clear answers to
certain questions from everybody.
It's not clear to me that the CTTE is allowed to rule on a bunch of
those questions, especially
Adrian Bunk writes (Re: Bug#727708: Init system resolution open questions):
(Only as a PM since I am repeating myself.)
Thanks for your mail. I think it deserves wider consideration.
One question you should consider adding:
* What switching between init systems has to be supported
]] Ian Jackson
Tollef Fog Heen writes (Bug#727708: Init system resolution open questions):
[Ian Jackson]:
As I mentioned on IRC, I think we need to get some clear answers to
certain questions from everybody.
It's not clear to me that the CTTE is allowed to rule on a bunch
On Thu, Jan 16, 2014 at 01:01:51PM -0800, Russ Allbery wrote:
I think that major packages that would be considered release blockers,
which probably includes GNOME, KDE, and Xfce, need to support the default
Linux init system in the sense that, if they don't, I don't think we can
release.
I
Moritz Muehlenhoff dixit:
FreeBSD upstream isn't a desktop OS and never will be, there're just too
many deficiencies (e.g. lack of dbus
Eh, excuse me! It’s obviously possible to run a desktop without dbus!
In fact, this is a feature, in my eyes.
limited hardware support
Oh c’mon. Linux does
On Thu, Jan 16, 2014 at 12:08:41PM -0800, Russ Allbery wrote:
Ian Jackson ijack...@chiark.greenend.org.uk writes:
AFAICT we are all agreed that:
* Applications which aren't part of the init system must not require a
particular init to be pid 1. (So in particular a desktop
Steve Langasek vor...@debian.org writes:
I don't believe we need to know the answer to these questions to know
that Ian's requirement is a correct one. If we are saying that packages
cannot drop their sysvinit scripts in jessie in order to ensure smooth
upgrades, then the same requirement
I think what we need to decide at the meeting later today is:
* Are we ready to make a decision ?
* If anyone is not, what other information/research/etc. is required
and how long will that take ?
* If we are ready, what resolution texts should we be voting on ?
* If we are ready, can
It turns out that we aren't quite ready. Don and Andreas say they
will reply with their views by the end of the weekend.
In particular we aren't settled on the support/enforcement/
requirement/status of the various sytems on the various platforms.
AFAICT we are all agreed that:
* sysv support
Ian Jackson writes (Re: Bug#727708: Init system resolution open questions):
As I mentioned on IRC, I think we need to get some clear answers to
certain questions from everybody.
My answers:
* For which init systems should there be a low nmu threshold for
native support in packages
On Thu, 2014-01-16 at 19:12 +, Ian Jackson wrote:
AFAICT we are all agreed that:
* Applications which aren't part of the init system must not require a
particular init to be pid 1. (So in particular a desktop
environment may not require a particular pid 1.)
I read the log, and I
Ian Jackson ijack...@chiark.greenend.org.uk writes:
AFAICT we are all agreed that:
* Applications which aren't part of the init system must not require a
particular init to be pid 1. (So in particular a desktop
environment may not require a particular pid 1.)
I still have concerns
]] Ian Jackson
As I mentioned on IRC, I think we need to get some clear answers to
certain questions from everybody.
It's not clear to me that the CTTE is allowed to rule on a bunch of
those questions, especially the RC bug ones seem to directly contradict
both 6.3.5 and 6.3.6 in the
Hi,
Ian Jackson ijack...@chiark.greenend.org.uk writes:
AFAICT we are all agreed that:
[...]
* Applications which aren't part of the init system must not require a
particular init to be pid 1. (So in particular a desktop
environment may not require a particular pid 1.)
What about
Ian Jackson ijack...@chiark.greenend.org.uk writes:
As I mentioned on IRC, I think we need to get some clear answers to
certain questions from everybody.
* For which init systems should there be a low nmu threshold for
native support in packages ?
I believe this should be the Linux
On Thu, Jan 16, 2014 at 09:39:37PM +0100, Ansgar Burchardt wrote:
...
Maintainers only should not drop support for a (default) init system
when the application supports it.
...
So if udev (maintained by systemd upstream as part of the systemd
sources) would ever get a dependency on systemd
Hi,
Adrian Bunk b...@stusta.de writes:
On Thu, Jan 16, 2014 at 09:39:37PM +0100, Ansgar Burchardt wrote:
...
Maintainers only should not drop support for a (default) init system
when the application supports it.
...
So if udev (maintained by systemd upstream as part of the systemd
sources)
35 matches
Mail list logo
