Bug#727708: multiple init systems - formal resolution proposal
Hi, Bdale Garbee: I'm not comfortable with a mandate that packages may not require a specific init system as pid 1. Could we (or rather, the CTTE) compromise on packages may mandate the default init system? -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
On Sat, 01 Feb 2014, Steve Langasek wrote: Where would this ballot option rank vis-à-vis FD, for those TC members who are opposed to the loose coupling option? I'm planning on ranking everything above FD. However, I would rank this particular option at the same level as L. == dependencies rider version S (split-the-init) == [...] Software not part of an init system's implementation may require interfaces unrelated to service management that are provided as part of an init system, but the dependency on such interfaces must be declared in a way that allows the dependency to be satisfied by compatible implementations on other init systems. I think requiring maintainers to implement this isn't tenable; maintainers should accept technically viable patches which do this, and if they do not, the CTTE can be invoked to resolve the problem. But that said, if this is an option that needs to be on the ballot, we should get it there quickly. -- Don Armstrong http://www.donarmstrong.com Democracy means simply the bludgeoning of the people by the people for the people. -- Oscar Wilde -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Steve Langasek writes (Re: Bug#727708: multiple init systems - formal
resolution proposal):
As things stand, it seems that each set of dependency rider options will
have some members of the TC voting them below FD. Which means I don't think
we've actually gotten to the bottom of this issue and identified the
consensus position, and I think we should be doing so.
I think that there probably isn't a consensus position.
Where would this ballot option rank vis-à-vis FD, for those TC members who
are opposed to the loose coupling option?
Well, I'm not one of those so your question is not really aimed at me.
But your S is for me basically a version of T, so I don't like it for
that reason. (To an extent, the first and second sentences of the 2nd
para are contradictory, and I don't think that's helpful.)
And the requirement you set out about dependencies is IMO too
technologically specific, and ought to be covered by the 3rd
paragraph about reasonable patches.
AFAICT neither Russ or Bdale have directly answered your question.
Given that and what I have said, do you want (a) to discuss this
further (perhaps with another irc drafting meeting) (b) to vote on
{T,L}{D,U,O,R} etc. (c) to propose your S or some variant on it as
well (as S{D,U,O,R} I expect) (d) something else ?
Thanks,
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Ian Jackson ijack...@chiark.greenend.org.uk writes: Steve Langasek writes: Where would this ballot option rank vis-à-vis FD, for those TC members who are opposed to the loose coupling option? [...] AFAICT neither Russ or Bdale have directly answered your question. I thought I did, sorry. I would rank those options below FD for any init system other than systemd. I'm still unsure how to vote option L with systemd. I'm not certain whether it would be better to adopt systemd with a bad package dependency model or adopt upstart with what I think is the correct package dependency model. It's a rather annoying decision to have to make. upstart with a bad package dependency model just seems all-around awful and worse in some respects than the status quo. But regardless, I would vote S next to L in all cases; there's no functional difference for me. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Plus sysvinit support isn't forever, since eventually it will be deprecated as more and more parts of the system drop support for it. Why? There is nothing wrong with sysv init for most of us. Why is there insistance (or seemingly triumphal predictions) that those of us who are happy with the status quo ante bellum (aka: *NIX) be left out in the cold. In Debian you can choose your file system during install. You can choose if you want a desktop or server style of install (different sets of packages). You can choose your language. And all these are supported yea after year after year, even hard things like language. Yet we cannot have the same for system five init, in perpetuity, like the rest? Sysv just has to bit rot away (it's made of wood?) It usually doesn't need to be touched for years on end, because it, like an SLR lens, just works, for decades, and if allowed to simply continue to exist: a century, more. It is stable, it does its job, it is simple. Like a lens. Unless you go and destroy it, it will continue to bend light long past you or I are dead. I think that's the problem some people have with it: they want to make their mark on linux, they see the init system as a old and thus frail target to execute and replace. For their own glory. Sysvinit is old, but it is not frail. It is as solid as any piece of software can possibly be, and it doesn't require mutilation for the benefit and glory of some new upstarts who were conceived 20 years into its reign. Thus it needs to be murdered apparently, and all of us who know it, appreciate it, have our knowlge based on it and other parts of traditional unix, well we can go into the grave with it apparently.
Bug#727708: multiple init systems - formal resolution proposal
The point that is being made is not you can't run software with shell scripts if you want, it's don't expect developers to write or maintain them for you. Regards, James Rhodes. On 3 February 2014 12:48, Thilos Rich thilos.r...@aol.com wrote: Plus sysvinit support isn't forever, since eventually it will be deprecated as more and more parts of the system drop support for it. Why? There is nothing wrong with sysv init for most of us. Why is there insistance (or seemingly triumphal predictions) that those of us who are happy with the status quo ante bellum (aka: *NIX) be left out in the cold. In Debian you can choose your file system during install. You can choose if you want a desktop or server style of install (different sets of packages). You can choose your language. And all these are supported yea after year after year, even hard things like language. Yet we cannot have the same for system five init, in perpetuity, like the rest? Sysv just has to bit rot away (it's made of wood?) It usually doesn't need to be touched for years on end, because it, like an SLR lens, just works, for decades, and if allowed to simply continue to exist: a century, more. It is stable, it does its job, it is simple. Like a lens. Unless you go and destroy it, it will continue to bend light long past you or I are dead. I think that's the problem some people have with it: they want to make their mark on linux, they see the init system as a old and thus frail target to execute and replace. For their own glory. Sysvinit is old, but it is not frail. It is as solid as any piece of software can possibly be, and it doesn't require mutilation for the benefit and glory of some new upstarts who were conceived 20 years into its reign. Thus it needs to be murdered apparently, and all of us who know it, appreciate it, have our knowlge based on it and other parts of traditional unix, well we can go into the grave with it apparently.
Bug#727708: multiple init systems - formal resolution proposal
Don't be facetious. The point that is being made is: F U C K system v init. F U C K anyone who relies on it, uses it, likes it, we will not help you, we will not continue on with it, F U C K U N I X, F U C K old sys admins. You say it in many clever ways, but don't think we don't get the message. As was said before: SystemD feels like an invasion, because it and its priests are spearheading just that. I now know to 1/100th of a degree what the pagans of europe felt. Debian provides all manners of different languages and support for them Debian provides various different kernels to run, and different versions of different kernels aswell as build systems should you choose to run some other kernel. Debian should continue to provide the simple sysvinit (for most daemons) scripts that it always has. It is usually not hard to start up a daemon. The standard debian init scripts are usually fine, just change which binary it runs etc. Not much support is needed: keep your hands off the init scripts and they'll keep working as they have for most daemons. So stop being facetious and telling us to go and fk ourselves while claiming you arent. And respect your elders please too, they use, like, would like to continue to use system V init, and not be goaded into being corralled into your new cattle pen. -Original Message- From: James Rhodes jrho...@redpointsoftware.com.au To: Thilos Rich thilos.r...@aol.com; 727708 727...@bugs.debian.org Sent: Mon, Feb 3, 2014 2:00 am Subject: Re: Bug#727708: multiple init systems - formal resolution proposal The point that is being made is not you can't run software with shell scripts if you want, it's don't expect developers to write or maintain them for you. Regards, James Rhodes. On 3 February 2014 12:48, Thilos Rich thilos.r...@aol.com wrote: Plus sysvinit support isn't forever, since eventually it will be deprecated as more and more parts of the system drop support for it. Why? There is nothing wrong with sysv init for most of us. Why is there insistance (or seemingly triumphal predictions) that those of us who are happy with the status quo ante bellum (aka: *NIX) be left out in the cold. In Debian you can choose your file system during install. You can choose if you want a desktop or server style of install (different sets of packages). You can choose your language. And all these are supported yea after year after year, even hard things like language. Yet we cannot have the same for system five init, in perpetuity, like the rest? Sysv just has to bit rot away (it's made of wood?) It usually doesn't need to be touched for years on end, because it, like an SLR lens, just works, for decades, and if allowed to simply continue to exist: a century, more. It is stable, it does its job, it is simple. Like a lens. Unless you go and destroy it, it will continue to bend light long past you or I are dead. I think that's the problem some people have with it: they want to make their mark on linux, they see the init system as a old and thus frail target to execute and replace. For their own glory. Sysvinit is old, but it is not frail. It is as solid as any piece of software can possibly be, and it doesn't require mutilation for the benefit and glory of some new upstarts who were conceived 20 years into its reign. Thus it needs to be murdered apparently, and all of us who know it, appreciate it, have our knowlge based on it and other parts of traditional unix, well we can go into the grave with it apparently.
Bug#727708: multiple init systems - formal resolution proposal
we will not help you If you want to run a configuration that is not supported by a developer, then no, I would not expect them to help you. Free software does not entitle you to free help, nor does it entitle you to demand others do or don't do things a particular way.
Bug#727708: multiple init systems - formal resolution proposal
On Sun, Feb 02, 2014 at 09:30:36PM -0500, Thilos Rich wrote: Don't be facetious. The point that is being made is: Thilos, James, this is not the appropriate place for you to have this conversation. Please leave this bug for its intended purpose, which is the technical commitee's discussion of init system selection for Debian. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: multiple init systems - formal resolution proposal
On Sun, Feb 02, 2014 at 09:30:36PM -0500, Thilos Rich wrote: Don't be facetious. The point that is being made is: F U C K system v init. F U C K anyone who relies on it, uses it, likes it, we will not help you, we will not continue on with it, F U C K U N I X, F U C K old sys admins. No, what they're saying, if anything, is If you're not willing to learn, you really should be. You say it in many clever ways, but don't think we don't get the message. As was said before: SystemD feels like an invasion, because it and its priests are spearheading just that. I now know to 1/100th of a degree what the pagans of europe felt. Debian provides all manners of different languages and support for them Debian provides various different kernels to run, and different versions of different kernels aswell as build systems should you choose to run some other kernel. Debian should continue to provide the simple sysvinit (for most daemons) scripts that it always has. It is usually not hard to start up a daemon. The standard debian init scripts are usually fine, just change which binary it runs etc. Not much support is needed: keep your hands off the init scripts and they'll keep working as they have for most daemons. So stop being facetious and telling us to go and fk ourselves while claiming you arent. Um, that's exactly what he's saying they're going to do. The maintainers are probably going to keep the SysV scripts in there, however most will probably not want to bother maintaining them, as systemd units (and I would suspect) upstart jobs are much easier to write and maintain. If you've got a serious problem with that, then you can always write or maintain your own. If the init script needs no changing, then you're all good, but eventually some are going to need changes, and that burden might very well fall on the users. And respect your elders please too, they use, like, would like to continue to use system V init, and not be goaded into being corralled into your new cattle pen. I've only been using Linux for 5 years, so what I say probably means nothing to you, however people that have been using Linux and Unix for decades are not all opposed to using systemd or Upstart. I really would do some research if I were you on why they're wanting to switch. It would probably shed a lot more light on your problems than what I can say in this email. -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpTUS6U_7PT1.pgp Description: PGP signature
Bug#727708: multiple init systems - formal resolution proposal
On Wed, Jan 29, 2014 at 10:13:25PM +0200, Adrian Bunk wrote: No, Josselin was making the technical claim that GNOME 3.10 would need a working logind even for basic functionality. So if it is possible to get the basic functionality of GNOME 3.10 without a working logind, his claim is just plain wrong. And when I was asking him for the technical details that would back up such a strong claim, he was not able to deliver. And that does matter a lot, since such claims seem to be the basis of all these GNOME in jessie needs systemd or with multiple init systems, GNOME will need a dependency on systemd (and Josselin even expects an exception from the release managers for that if the TC decision would not allow such a dependency [1]). Whether or not it's possible for GNOME in jessie to be made to work without logind, I agree with the GNOME team that logind is a reasonable dependency for GNOME to have on Linux. What is not reasonable is the chain of logic that leads from GNOME should use logind to GNOME will require systemd as the init system. logind v204 (and the other systemd dbus services) have been made to run on non-systemd-PID1 systems. Work is ongoing to provide an alternative implementation of a cgroup single-writer, that can then expose a systemd-compatible interface for use with logind v205. These are not blue-sky hypotheticals; the first exists in Debian unstable already as the systemd-shim package, the second is available as an upstream project (http://cgmanager.linuxcontainers.org/) that will be suitable for use in Debian well before the jessie release. And I have already offered my support to the systemd maintainers to support this configuration going forward. Yet when I challenge the assertion that desktop N will require systemd, therefore Debian must adopt systemd as PID 1, which has been repeated endlessly in this discussion, I am chided for being insufficiently courteous to people who do not have the facts on their side. I have previously suggested that the GNOME team has a reputation for obstructionism. I owe the GNOME team an apology for this; as was made clear to me, in my efforts to not overly personalize the discussion, I instead erred in the opposite direction by tarring the entire GNOME team with the same brush. I will instead limit my criticism to Josselin, who despite giving the impression of being the spokesman for the GNOME team, is apparently not speaking for the team as he seeks to cloud the issues around the technical choices that face this committee. Assertions that desktops' dependencies on logind dictate the use of systemd as PID1 are at best a self-fulfilling prophecy which creates a climate in which people are dissuaded from even trying to do the work to provide alternatives because they believe these efforts will be blocked by the GNOME team; and at worst, an overt attempt to distort the TC's debate on the init question. Josselin has asserted not only that he considers systemd-as-init a hard dependency for GNOME in jessie, but that he expects the release team to side with him over the Technical Committee if the TC does not agree with him. This is unconscionable, given that there are two very straightforward and obvious technical solutions to this problem: - split the systemd package (as previously discussed) into separate binaries, for the init system vs. the dbus interfaces, and have GNOME depend on the latter - have the systemd package declare one or more virtual packages via Provides:, which GNOME packages depend on and one or more alternative implementations may also provide. It is possible that, at the end of the release cycle, there will be only one viable implementation of these interfaces, and Josselin's prediction will be proven out. However, it is crucially not the place of GNOME maintainers to decide a priori that this *will* be the case, particularly when it should be clear to everyone that there are developers (myself included) interested in doing the work to make these dbus services work on top of other init systems. This is contrary to the spirit of Debian, and contrary to the very principle of reasonable accomodation that Russ espoused on this very bug last month. And so I am greatly dismayed by the position Russ and Bdale have taken in this discussion with respect to packages being allowed to depend on a specific init system. Both have expressed the opinion that Debian should remain open to alternative init implementations as long as there are developers willing to do the work; but when it comes to concrete examples of ways in which conflation between init system (that is, service registration and service management) interfaces and dbus service interfaces directly interfere with that goal, they have been unwilling to stand up for the relevant technical principle. This despite the fact that the burden on the GNOME maintainers to support alternate implementations of these dbus services is much lower than the
Bug#727708: multiple init systems - formal resolution proposal
Steve Langasek writes (Bug#727708: multiple init systems - formal resolution proposal): Thus, for me, all of the T variants in Ian's latest draft (21226.41292.366504.997...@chiark.greenend.org.uk) rank below FD. Note that there is a difference, of course, between GR and FD, in the voting system. If the vote on option X vs GR is 4:4, Bdale might be able to use his casting vote in favour of X. If the vote on option X vs FD is 4:4, the option is eliminated and cannot win. Personally, for this reason, I am not going to rank any options between GR and FD. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Steve Langasek writes (Bug#727708: multiple init systems - formal resolution
proposal):
[stuff]
Thanks for that, which I mostly agree with.
On Wed, Jan 29, 2014 at 10:13:25PM +0200, Adrian Bunk wrote:
Thus, for me, all of the T variants in Ian's latest draft
(21226.41292.366504.997...@chiark.greenend.org.uk) rank below FD.
In my mail following the irc meeting I formally proposed the options
you see listed in that message: {U,D,O,V}{T,F} and GR and FD.
Are you satisfied that the wordings I propose there properly capture
the essence of the disagreement ? (You haven't said this explicitly,
but I get the impression that you think they do.)
If not then please say so right away. If you have better ideas you
should probably formally propose amendment(s), since the current
situation is that we are in the discussion period and are likely to
start the vote on Monday.
If you _are_ satisfied that the options on the ballot sufficiently
capture the essence of the dispute, then saying so would be helpful as
it might allow us to start the vote sooner.
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Steve Langasek vor...@debian.org writes: And so I am greatly dismayed by the position Russ and Bdale have taken in this discussion with respect to packages being allowed to depend on a specific init system. Both have expressed the opinion that Debian should remain open to alternative init implementations as long as there are developers willing to do the work; but when it comes to concrete examples of ways in which conflation between init system (that is, service registration and service management) interfaces and dbus service interfaces directly interfere with that goal, they have been unwilling to stand up for the relevant technical principle. You can be dismayed all you want, but I completely disagree with you about the shape of the relevant principle. There is a huge difference between being open to alternative init implementations and requiring that maintainers implement support for alternative init systems, which is what the loose coupling option requires. The latter is, in my opinion, effectively an attempt to coerce maintainers into doing work they don't want to do by holding their packages hostage, which is something that I think we should only do for things that are absolutely vital to the project. And I don't believe this is. What I want to see is people working with the relevant maintainers, understanding their concerns and issues, and find a way to provide maintainable support, not just asking the Technical Committee to force other people to change how they maintain their packages well in advance of actual irresolvable impasses. And when no one has done the work to port a particular package to another init system, preventing that current reality from being properly represented in dependencies just makes the distribution more technically fragile without any real gain for our users. This despite the fact that the burden on the GNOME maintainers to support alternate implementations of these dbus services is much lower than the burden of providing sysvinit startup compatibility in jessie for an upstream project that doesn't support it. The reason why requiring sysvinit startup compatibility makes sense to me is because everything in the archive *already* has sysvinit startup capability, and therefore what we're asking for is for maintainers to sustain the status quo through jessie as much as possible so that we can manage an orderly upgrade. I certainly hope that we're not going to have to maintain sysvinit scripts indefinitely. As Philipp Kern points out in 41b26b373019ab39ebff223603a08...@hub.kern.lc, this leaves us with the very real possibility that we will wind up with mutually incompatible sets of packages in the archive for jessie that are no longer coinstallable, not because the packages themselves have conflicting functionality, but because they've taken sides - intentionally or unintentionally - on the init system question. If we don't think such fragmentation of the Debian archive is an acceptable outcome (and I for one don't see any reason it should be), then we should say as much in our resolution. The committee has a duty to provide strong technical guidance to the project, not just to get involved after something has gone off the rails. If you want to explicitly say that packages are required to support the default init system, then you should propose language. That's not what the loose coupling option says. The loose coupling option says that all packages must support *all* init systems, with some possible degredation of operation. I believe that effectively locks us into supporting sysvinit scripts forever, since no alternative universal common denominator seems to be emerging. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
On Sat, Feb 01, 2014 at 07:28:49PM +, Ian Jackson wrote:
Steve Langasek writes (Bug#727708: multiple init systems - formal resolution
proposal):
Thus, for me, all of the T variants in Ian's latest draft
(21226.41292.366504.997...@chiark.greenend.org.uk) rank below FD.
In my mail following the irc meeting I formally proposed the options
you see listed in that message: {U,D,O,V}{T,F} and GR and FD.
Are you satisfied that the wordings I propose there properly capture
the essence of the disagreement ? (You haven't said this explicitly,
but I get the impression that you think they do.)
I believe they capture the essence of the disagreement as it's been framed
so far in this discussion. However, I'm hoping that there is a compromise,
involving being more explicit about the interoperability expected between
packages so that they remain coinstallable on a Debian system and don't
fragment the archive, that is agreeable to all members of the TC.
As things stand, it seems that each set of dependency rider options will
have some members of the TC voting them below FD. Which means I don't think
we've actually gotten to the bottom of this issue and identified the
consensus position, and I think we should be doing so.
Where would this ballot option rank vis-à-vis FD, for those TC members who
are opposed to the loose coupling option?
== dependencies rider version S (split-the-init) ==
This decision is limited to selecting a default initsystem; we
continue to welcome contributions of support for all init systems.
Software outside of an init system's implementation may not require a
specific init system to be pid 1, although degraded operation is
tolerable. Software not part of an init system's implementation may
require interfaces unrelated to service management that are provided as
part of an init system, but the dependency on such interfaces must be
declared in a way that allows the dependency to be satisfied by
compatible implementations on other init systems.
Maintainers are encouraged to accept technically sound patches
to enable improved interoperation with various init systems.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
Bug#727708: multiple init systems - formal resolution proposal
Steve Langasek vor...@debian.org writes: Where would this ballot option rank vis-à-vis FD, for those TC members who are opposed to the loose coupling option? == dependencies rider version S (split-the-init) == This decision is limited to selecting a default initsystem; we continue to welcome contributions of support for all init systems. Software outside of an init system's implementation may not require a specific init system to be pid 1, although degraded operation is tolerable. Software not part of an init system's implementation may require interfaces unrelated to service management that are provided as part of an init system, but the dependency on such interfaces must be declared in a way that allows the dependency to be satisfied by compatible implementations on other init systems. Maintainers are encouraged to accept technically sound patches to enable improved interoperation with various init systems. This continues to lock all package maintainers into providing startup configuration for all init systems indefinitely, and therefore to me is basically equivalent to L. If you limited the may not require a specific init system part to only jessie, I would vote it above FD, unless there's some problem with it that's not immediately apparent to me. (I would still find L with that modification problematic, although less so than then current L.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Russ Allbery wrote: Steve Langasek vor...@debian.org writes: And so I am greatly dismayed by the position Russ and Bdale have taken in this discussion with respect to packages being allowed to depend on a specific init system. Both have expressed the opinion that Debian should remain open to alternative init implementations as long as there are developers willing to do the work; but when it comes to concrete examples of ways in which conflation between init system (that is, service registration and service management) interfaces and dbus service interfaces directly interfere with that goal, they have been unwilling to stand up for the relevant technical principle. You can be dismayed all you want, but I completely disagree with you about the shape of the relevant principle. There is a huge difference between being open to alternative init implementations and requiring that maintainers implement support for alternative init systems, which is what the loose coupling option requires. The latter is, in my opinion, effectively an attempt to coerce maintainers into doing work they don't want to do by holding their packages hostage, which is something that I think we should only do for things that are absolutely vital to the project. And I don't believe this is. What I want to see is people working with the relevant maintainers, understanding their concerns and issues, and find a way to provide maintainable support, not just asking the Technical Committee to force other people to change how they maintain their packages well in advance of actual irresolvable impasses. And when no one has done the work to port a particular package to another init system, preventing that current reality from being properly represented in dependencies just makes the distribution more technically fragile without any real gain for our users. Well said. In particular, in the case of GNOME, I don't see any package in the archive yet for a fork of logind that depends on systemd-shim instead of systemd, so there's no alternative available for GNOME to depend on. There's little point to adding a virtual package with no providers yet, because until the cloud of uncertainty leading to 727708 gets resolved, a (direct or indirect) dependency on systemd-sysv | empty-alternative seems unlikely to fly, and seems likely to lead to more rants against the GNOME maintainers for depending on systemd. It should be completely trivial to introduce a virtual org-freedesktop-login1 package (modulo any complexities introduced by interface versioning for new methods added to that interface). However, it also seems pointless until there's a prospective provider of that interface. Do you have a package ready to provide that interface such that GNOME can depend on it? I've seen no signs that the GNOME maintainers would refuse to allow alternative providers of those interfaces once they exist, just refusals to do any work in that direction until those alternatives *do* exist, which seems entirely reasonable. (I'm specifically leaving out the possibility of splitting systemd's logind out of the systemd package and forcing it to allow alternatives to a systemd dependency. As effectively demonstrated by the ongoing work to port logind 204 to cgmanager, there is a non-trivial amount of work required for forks of logind to keep up with the ongoing development of logind and systemd, and putting that work on the systemd package will lead to future packaging delays similar to the one currently blocking a transition past 204. To echo Russ's comments, we should not hold the systemd packages hostage to force their maintainers to maintain compatibility with non-systemd. Any such work will inherently be a fork; better to properly represent it as one and package it as one, to avoid hampering the unforked version.) This despite the fact that the burden on the GNOME maintainers to support alternate implementations of these dbus services is much lower than the burden of providing sysvinit startup compatibility in jessie for an upstream project that doesn't support it. The reason why requiring sysvinit startup compatibility makes sense to me is because everything in the archive *already* has sysvinit startup capability, and therefore what we're asking for is for maintainers to sustain the status quo through jessie as much as possible so that we can manage an orderly upgrade. I actually have language written up that would phrase the sysvinit compatibility requirement for jessie as specifically a requirement to properly support upgrades from wheezy to jessie, which I think would make more sense. In particular, that language defined exactly what degree of degraded functionality must be supported under sysvinit: enough to upgrade from wheezy to jessie, and from sysvinit to not-sysvinit, in either order, in any environment [including a graphical one]. I certainly hope that we're not going to have to maintain
Bug#727708: multiple init systems - formal resolution proposal
Josh Triplett j...@joshtriplett.org writes: It should be completely trivial to introduce a virtual org-freedesktop-login1 package (modulo any complexities introduced by interface versioning for new methods added to that interface). However, it also seems pointless until there's a prospective provider of that interface. Do you have a package ready to provide that interface such that GNOME can depend on it? I've seen no signs that the GNOME maintainers would refuse to allow alternative providers of those interfaces once they exist, just refusals to do any work in that direction until those alternatives *do* exist, which seems entirely reasonable. Note that I don't think it makes sense for Steve to work on such a package right now for exactly the same reason that I don't think it makes sense to start adding virtual packages right now, or figuring out the dependency structure in GNOME for non-systemd logind right now. Personally, I wouldn't want to work on any of those things until some of the currently extremely large probability space collapses. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
On Sat, Feb 01, 2014 at 01:21:19PM -0800, Russ Allbery wrote: Josh Triplett j...@joshtriplett.org writes: It should be completely trivial to introduce a virtual org-freedesktop-login1 package (modulo any complexities introduced by interface versioning for new methods added to that interface). However, it also seems pointless until there's a prospective provider of that interface. Do you have a package ready to provide that interface such that GNOME can depend on it? I've seen no signs that the GNOME maintainers would refuse to allow alternative providers of those interfaces once they exist, just refusals to do any work in that direction until those alternatives *do* exist, which seems entirely reasonable. Note that I don't think it makes sense for Steve to work on such a package right now for exactly the same reason that I don't think it makes sense to start adding virtual packages right now, or figuring out the dependency structure in GNOME for non-systemd logind right now. Personally, I wouldn't want to work on any of those things until some of the currently extremely large probability space collapses. I agree entirely; I was simply indicating (in other parts of my previous mail) that in the absence of a package ready to provide org-freedesktop-login1, a dependency (indirect or direct) on systemd's logind or org-freedesktop-login1 would reduce to a dependency on systemd as PID 1. - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
On Sat, Feb 01, 2014 at 01:12:34PM -0800, Josh Triplett wrote: In particular, in the case of GNOME, I don't see any package in the archive yet for a fork of logind that depends on systemd-shim instead of systemd, so there's no alternative available for GNOME to depend on. There is no fork of logind *required* today. This bug would be fixed, today, by a dependency on 'systemd-shim | systemd-sysv', which is what I asked for in the bug. There's little point to adding a virtual package with no providers yet, because until the cloud of uncertainty leading to 727708 gets resolved, a (direct or indirect) dependency on systemd-sysv | empty-alternative seems unlikely to fly, and seems likely to lead to more rants against the GNOME maintainers for depending on systemd. Of course, because that would be forcing a non-default init system (forcing installation of systemd-sysv before the decision has been taken on the default init system). As things stand today, a dependency on systemd-shim | systemd-sysv would fix the bug for our users without forcing a change of init system on upgrade. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: multiple init systems - formal resolution proposal
On Sat, Feb 01, 2014 at 05:23:11PM -0500, Steve Langasek wrote: On Sat, Feb 01, 2014 at 01:12:34PM -0800, Josh Triplett wrote: In particular, in the case of GNOME, I don't see any package in the archive yet for a fork of logind that depends on systemd-shim instead of systemd, so there's no alternative available for GNOME to depend on. There is no fork of logind *required* today. Only because the same cloud of uncertainty is blocking an update of systemd past version 204, and even then only assuming you pull in logind from the systemd package and use it with systemd-shim, which leads to yet another lovely pile of controversy. This bug would be fixed, today, by a dependency on 'systemd-shim | systemd-sysv', which is what I asked for in the bug. Which would break systems that have the systemd package installed and in use via init=/bin/systemd. (In the interests of keeping discussion in one place rather than two, let's keep the discussion of solutions to that particular bug in that bug, rather than here, please.) There's little point to adding a virtual package with no providers yet, because until the cloud of uncertainty leading to 727708 gets resolved, a (direct or indirect) dependency on systemd-sysv | empty-alternative seems unlikely to fly, and seems likely to lead to more rants against the GNOME maintainers for depending on systemd. Of course, because that would be forcing a non-default init system (forcing installation of systemd-sysv before the decision has been taken on the default init system). As things stand today, a dependency on systemd-shim | systemd-sysv would fix the bug for our users without forcing a change of init system on upgrade. Leaving the aforementioned breakage aside, there's also the issue that other parts of GNOME will need more than just what systemd-shim currently provides, and having inconsistent dependencies in the GNOME packages makes no sense. Furthermore, having systemd-shim installed will make upgrades to a post-727708 future version of Debian with systemd installed that much more painful, since there's no straightforward way for package dependencies to switch from systemd-shim to systemd|systemd-shim correctly. Seems preferable to see the outcome of 727708 first, the result of which might well lead the GNOME packages to depend on systemd-sysv | systemd-shim instead, or perhaps on systemd-sysv | org-freedesktop-login1 if that proves logistically easier. - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
On Sat, Feb 01, 2014 at 11:25:01AM -0500, Steve Langasek wrote: Josselin has asserted not only that he considers systemd-as-init a hard dependency for GNOME in jessie, but that he expects the release team to side with him over the Technical Committee if the TC does not agree with him. This is unconscionable, given that there are two very straightforward and obvious technical solutions to this problem: - split the systemd package (as previously discussed) into separate binaries, for the init system vs. the dbus interfaces, and have GNOME depend on the latter I the light of what I know about this issue from the systemd side, splitting the package into multiple independent components is much harder than it looks. For one, logind used to call into PID1 for shutdown/suspend/... but not it'll also attempt to start the user manager and tell PID1 to manage resource limits. I don't suppose systemd-shim is ready for that. Second, logind uses journald for logging. This actually is also an issue for gnome: gdm now logs to the journal, which makes debugging gdm initialization issues so much easier. Recently patches which redirect X logs to the journal have been accepted (even if not merged yet afaik) [1]. The hypothethical systemd-logind package would not only use a different provider of the most crucial services, but would also lose existing logging mechanism. Apart from that, loginctl communicates with PID1 to show cgroup information... Put in a lot of work to build a more brittle system and lose functionality? Even if it might have been easier for old systemd versions, the components are now fairly tightly coupled. Even if such a split could be done with enough man-hours thrown at it, I think it's obvious why Joss and other people who use systemd aren't thrilled about the prospect, especially with #727708 undecided. - have the systemd package declare one or more virtual packages via Provides:, which GNOME packages depend on and one or more alternative implementations may also provide. As argued elsewhere, since there are no alternative providers, this would amount to a hard dependency on systemd, which gnome is not allowed to do. Josselin's stance, even if strongly expressed, seems accurate. [1] https://bugzilla.gnome.org/show_bug.cgi?id=722889 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
On Sat, Feb 1, 2014 at 11:25 AM, Steve Langasek wrote: On Wed, Jan 29, 2014 at 10:13:25PM +0200, Adrian Bunk wrote: And that does matter a lot, since such claims seem to be the basis of all these GNOME in jessie needs systemd or with multiple init systems, GNOME will need a dependency on systemd (and Josselin even expects an exception from the release managers for that if the TC decision would not allow such a dependency [1]). Whether or not it's possible for GNOME in jessie to be made to work without logind, I agree with the GNOME team that logind is a reasonable dependency for GNOME to have on Linux. What is not reasonable is the chain of logic that leads from GNOME should use logind to GNOME will require systemd as the init system. The logic is simple. That is now clearly the direction that gnome upstream is heading. If the gnome maintainers don't want to diverge too much from upstream, why force them? Yet when I challenge the assertion that desktop N will require systemd, therefore Debian must adopt systemd as PID 1, which has been repeated endlessly in this discussion, I am chided for being insufficiently courteous to people who do not have the facts on their side. I think it would be far more effective to redirect the debate toward figuring out how to support a gnome island that is systemd-only without forcibly changing the rest of Debian to accommodate their world (i.e. deciding a new default init), and to do so without criticizing those involved. Criticism only fortifies your opposition's resolve, and that is why it is now so difficult to work toward out any compromise. Let's stick with sysvinit for jessie, and in the meantime let the project evolve technical solutions less tied to the gnome island. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
Le jeudi 30 janvier 2014 à 22:43 +0400, Sergey B Kirpichev a écrit : https://wiki.debian.org/Debate/initsystem/systemd#sysvinit_.2B-_insserv Since you forgot to paste the first sentence, let me add it here. “Sysvinit was never designed to cope with the dynamic/event-based architecture of the current Linux kernel. The only reason why we still use it today is the cost of a migration.” Is this all? Yes, this is all. Anyone who knows how Linux works doesn’t consider sysvinit a viable choice today. There is no need for lengthy argumentations, because there is nothing to argue against. -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
On Wed, Jan 29, 2014 at 03:18:46PM -0800, Russ Allbery wrote: Given that, your opinions about the quality of GNOME upstream development don't seem relevant to the problem we're trying to resolve. If you don't like the software, don't use it. Unfortunately, it doesn't save us, as the set of constraints of this software may affect the future Debian policy. Do we have any other software, that right now forces other to switch the init system? If not, remove GNOME from Debian could be an option (and, may be, a good motivation for upstream to keep away from insane changes, be more LSB-compatible). There is no good reasons to change long-standing Debian policy about alternative inits. Let the people who are interested in making the software work figure out what that entails. People who are interested seems to be not interested in anything except satisfying their requirements by new Debian policy. But the Debian is not just a Gnome launcher. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
Matthias Klumpp dixit: 2014-01-30 ChaosEsque Team chaosesquet...@yahoo.com: [bullshit] This was actually *not* bullshit. The delivery of most of the content could use some polishing, but the content is a(n inconvenient) truth. Wasn't there some kind of a ban applied here? Apparently not, but it’s better that way, as the reasoning was something along the lines of the messages being off-topic, which they are clearly not, so I believe the ban to be in error, anyway. bye, //mirabilos -- diogenese Beware of ritual lest you forget the meaning behind it. igli yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
On Thu, Jan 30, 2014 at 12:05:05PM +, Thorsten Glaser wrote: This was actually *not* bullshit. The delivery of most of the content could use some polishing, but the content is a(n inconvenient) truth. Man, if someone was spouting garbage like that in support of systemd, you bet your mksh that I would call them on it[1] and try to seperate them from the sane people. Don't support the trolls, we're having a hard enough time keeping the signal ratio as high as it is - we don't need more over politicised garbage on the list. Much love, Paul [1]: I actually have, in fact, done this. There are people arguing for the position I support that I've told to back off from the thread. -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
Putting it another way, then, I expect there are some people who will not want systemd on their GNU/Linux systems. I don't think it matters if their reasons are technical, political, irrational fear or personal dislike of the creator; I'd like them to have that choice and for it to work as well as possible. Whatever init system we use on the non-Linux ports (which will certainly not be systemd), I expect it will be fully available to Debian GNU/Linux installs, with init scripts that we'd have to maintain already for the sake of our ports. Hopefully that is some reassurance. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
2014-01-30 Thorsten Glaser t...@mirbsd.de: Matthias Klumpp dixit: 2014-01-30 ChaosEsque Team chaosesquet...@yahoo.com: [bullshit] This was actually *not* bullshit. The delivery of most of the content could use some polishing, but the content is a(n inconvenient) truth. Wasn't there some kind of a ban applied here? Apparently not, but it’s better that way, as the reasoning was something along the lines of the messages being off-topic, which they are clearly not, so I believe the ban to be in error, anyway. First of all, I am sorry for leaking information and this rather rude reply - won't happen again. I was just very annoyed yesterday, but a more polite reply would still have been better (although I still think the arguments weren't valid) On thing about the whole dropping GNOME and punishing Lennart/the systemd team for pushing innovations without caring for how it was done prevously: What would be the effecr if we decided to drop GNOME, because it depends on systemd? Of course, Debian would have played with it's muscles, but in the end we would have lost GNOME users, all GNOME developers and many motivated people involved in taking care of GNOME. GNOME upstream won't really change, because they test the with-systemd codepath, which means they are running it. So we would have a great loss without any gain. What would happen if we adopted systemd? We could keep every software running as-it-is on Debian. People would not notice any issues, because (except for some bugs pending to be fixed, and the migration phase) a systemd-system does not break anything for Linux users (ask Arch, Fedora, OpenSUSE, ...). Of course, there is the kFreeBSD case. But instead of porting away each and every software from systemd to $other_init, in case of kFreeBSD we would just have to maintain portability patches for applications which want to run on this architecture. So, less work. For users of alternative kernels, they could also use sysvinit or anything else, because existing scripts won't stop working and new ones can be written which match the underlying alternative kernel (sysvinit is running on kFreeBSD due to some hacks to make /proc Linux-ish, so this kind of adaption is already happening). If we would drop systemd or anything which Lennart created, we would reject functionality without any technical reason to do so. The software written by Lennart fixes issues. That's why Wayland uses it and an X patch is pending, to make some new scenarios with X possible. People working on these projects are no idiots who add a dependency because they can, but because it seems to be the best solution in order to fix a problem for them. Of course, that could - in theory - be done differently, but nobody stepped up to write an alternative to systemd services, so systemd is used. Not using systemd fixes *none* of the problems, but results in much more work in future to make stuff work on Debian - so I don't really consider this to be a viable solution to anything. All of the above applies to upstart as well, but with the limitation that in case of using upstart we would still have to make upstart support systemd features and to carry additional patches to make all systemd services work well on that system. In the end: Dropping GNOME or systemd does not fix issues but is only hiding problems. Ignoring things written by the systemd people which are adopted by many upstream projects already will harm Debian more then simply adding them and making them work great (because that's what distributions should do: make upstream software work well together), no matter if systemd is running as init or not. Phew, waaay to much text... Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
Matthias Klumpp dixit: What would happen if we adopted systemd? The project would lose (a different set of) contributors and users. The OSS ecosystem would lose, vendor-lock-in would ensue in a way even worse than the FSF does, and the remnants of Unix/GNU in Debian would die, to be replaced by FLOS. The last “big” outpost of inde‐ pendence would go away. I don’t know which OS I’d use in place of Debian then (probably rather OpenBSD than Gentoo), in the places where I’m currently using, supporting or pushing Debian. Debian would follow the path of Red Hat, Inc. The LSB would die. The LPI people would probably rejoice, as they could drop everything other than systemd configs… Every single Unix or GNU sysadmin would have to relearn basically everything about system/service management. Oh, and don’t let me get started on “journal”… And, finally – last but definitely not least – nobody knows what Lennart and Co. would drop onto our heads *next* time. Or the GNOME people. And, by then, switching away would be even *more* reluctant work. software written by Lennart fixes issues. That's why Wayland uses it and an X patch is pending, to make some new scenarios with X possible. It also creates lots of issues (a common way to fix audio problems on contemporary Debian is “purge pulseaudio”, I kid you not!), and not everyone needs all those scenarios. I don’t mind Debian permitting people to use systemd as long as sysvinit support stays mandatory, and it is possible to install a Debian system without systemd/GNOME without needing to go through unreasonable things. Otherwise… well. In the end: Dropping GNOME or systemd does not fix issues but is only Well, it _would_ fix the current clash *and* give clear signals into the direction of KDE and hopefully XFCE people. Also, it would signal to people that they cannot just take over the entire OS like that. Distributions are *not* meant to be there to just look and do the same. Rather, the contrary. While their initial and foremost purpose is to make the bunch of packages in the GNU ecosystem installable and harmonise with each other, their job is also to offer a diverse choice. And the GNOME/systemd people are invited to make their dream of the FLOS GNOME OS into a Debian derivate or Pure Blend. bye, //mirabilos -- 08:05⎜XTaran:#grml mika: Does grml have an tool to read Apple ⎜System Log (asl) files? :) 08:08⎜ft:#grml yeah. /bin/rm. ;) 08:09⎜mrud:#grml hexdump -C 08:31⎜XTaran:#grml ft, mrud: *g* -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
Matthias Klumpp writes (Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.): What would be the effecr if we decided to drop GNOME, because it depends on systemd? In this hypothetical scenario: It would be fairly easy for a downstream of Debian to mandate systemd for their users, and provide Gnome. It would not be anywhere near as easy for a downstream of Debian to undo the assumption by Debian (de facto or de jure) of systemd as the one true init system. If it comes down to it I would prefer to drop Gnome than to make systemd mandatory for all of Debian's users and downstreams just because Gnome had introduced a hard dependency on systemd. Luckily this is all hypothetical. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
On 30/01/14 17:01, Thorsten Glaser wrote: And the GNOME/systemd people are invited to make their dream of the FLOS GNOME OS into a Debian derivate or Pure Blend. If the chosen default is something other than systemd, and if the TC resolution does not prevent GNOME having a hard dependency on systemd interfaces, then systemd would effectively belong to task-gnome-desktop That situation is basically how the pure blends work already? And it still means the Debian GNOME DVD could give the ideal setup for GNOME. And the 'default' can be decided irrespective of what GNOME needs? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
On Thu, Jan 30, 2014 at 05:30:04PM +0100, Matthias Klumpp wrote: What would be the effecr if we decided to drop GNOME, because it depends on systemd? Of course, Debian would have played with it's muscles, but in the end we would have lost GNOME users, all GNOME developers and many motivated people involved in taking care of GNOME. May be. On another hand, it this decision can attract more conservative (and, probably, experienced) people from other distributions. GNOME upstream won't really change Why? There are non-Linux GNOME users, for example. If the GNOME developers don't care even about such popular distribution as Debian - something is going wrong. And not with the Debian, for sure. We could keep every software running as-it-is on Debian. People would not notice any issues, because (except for some bugs pending to be fixed, and the migration phase) a systemd-system does not break anything for Linux users Please don't repeat here these myths. It does break things, it has bugs. Go to bugtrackers of mentioned distributions, go to the systemd's bugtracker. Last, but not least: http://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=yessrc=systemd If we would drop systemd or anything which Lennart created, we would reject functionality without any technical reason to do so. There are lots of reasons why we sometimes want to keep things simple and clean. A good example was mentioned in this thread: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#3155 That's why Wayland uses it and an X patch is pending, to make some new scenarios with X possible. People working on these projects are no idiots who add a dependency because they can, but because it seems to be the best solution in order to fix a problem for them. Are X-people indeed sacrifice portability, or there is something different (e.g. these dependencies are optional)? Not using systemd fixes *none* of the problems Where is the list of problems for sysvinit we intend to solve? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
Le jeudi 30 janvier 2014 à 21:38 +0400, Sergey B Kirpichev a écrit : [Lots of crap] Where is the list of problems for sysvinit we intend to solve? https://wiki.debian.org/Debate/initsystem/systemd#sysvinit_.2B-_insserv -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
Matthias Klumpp writes (Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.): What would be the effecr if we decided to drop GNOME, because it depends on systemd? In this hypothetical scenario: It would be fairly easy for a downstream of Debian to mandate systemd for their users, and provide Gnome. It would not be anywhere near as easy for a downstream of Debian to undo the assumption by Debian (de facto or de jure) of systemd as the one true init system. If it comes down to it I would prefer to drop Gnome than to make systemd mandatory for all of Debian's users and downstreams just because Gnome had introduced a hard dependency on systemd. Luckily this is all hypothetical. Ian. Hi Ian, I know that you are a respected Debian developer, but who are you to decide alone what kind of software which may be dropped from the archive? (I'm refering to ...I would prefer to drop Gnome...). Also, as far as I know Debian cares a lot about its users, who, according to popcon, seem to appreciate GNOME. Don't you care about them? Are you a proponent of a caste system in Debian, where all project that don't follow your precepts and vision risk to be kicked outside of Debian? As you have been pretty harsh against people maintaining those, again according to your precepts, second zone projects in Debian, please permit me to be as well, and let me tell you that you're a tiny despot, and you look worse than people you're trying to fight against! Have a good day, Bastien PS: I know that I'll probably undergo your ire, thus be banned from the list; as it seems you can grant you all the rights!
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
On Thu, Jan 30, 2014 at 06:47:02PM +0100, Josselin Mouette wrote: Le jeudi 30 janvier 2014 à 21:38 +0400, Sergey B Kirpichev a écrit : [Lots of crap] Nice argumentation, as usual... Where is the list of problems for sysvinit we intend to solve? https://wiki.debian.org/Debate/initsystem/systemd#sysvinit_.2B-_insserv * Sysvinit/insserv has very little C code, but the real code size must take shell scripts into account. These scripts come in huge numbers, contain bugs and are hard to maintain. - I don't see that this is a big problem. C is a low-level language and it's a good idea to implement some logic on a high-level scripting language. * Debugging an init script is a tedious task. [...] - Usually it's as simple as to add set +x * Sysvinit is insufficient for desktops. [...] But the real problems arise on big server setups, where Debian is losing ground because of its antiquated init system. - Debian is not only about desktops. - The second part is too subjective. A counterexample was provided in the reference, mentioned in my previous post. Is this all? Sounds like a bad joke. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
On Thu, Jan 30, 2014 at 6:38 PM, Sergey B Kirpichev skirpic...@gmail.com wrote: On Thu, Jan 30, 2014 at 05:30:04PM +0100, Matthias Klumpp wrote: GNOME upstream won't really change Why? There are non-Linux GNOME users, for example. If the GNOME developers don't care even about such popular distribution as Debian - something is going wrong. And not with the Debian, for sure. This has already been answered. GNOME advised all distributors 2 years ago. Nothing much happened. Meanwhile, we went ahead and relied more on systemd without really depending on systemd. You could implement the interfaces of the various bits without depending really on systemd. If after (seems it is going to be) 2.5 years you come back and say we'll, we decided on this while meanwhile we continued communicating our decisions and plans (we plan at least 6 months ahead), then, I find phrasings like don't care even about such popular distributions as Debian offensive. This as we provided ample opportunity to know our plans, to discuss, etc. Anyway, it seems you don't know what systemd provides and from your various responses it is pretty clear you cannot be bothered to investigate. It works fine for me is such an easy answer. Coming late to this bugreport and asking questions that have already been asked and answered many times before, yet feeling entitled to be able to talk about what others did: good luck with that, but as already mentioned to other people: I can provide the various emails that we reached out and did our best. I can also show you that all the questions you're asking have been asked and answered before. Maybe investigate a little bit before forming your opinion! Lastly, we have added *loads* and *loads* of new dependencies over the many years GNOME has existed. Regards, Olav -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
On Thu, Jan 30, 2014 at 12:04 PM, Ian Jackson wrote: What would be the effecr if we decided to drop GNOME, because it depends on systemd? In this hypothetical scenario: It would be fairly easy for a downstream of Debian to mandate systemd for their users, and provide Gnome. It would not be anywhere near as easy for a downstream of Debian to undo the assumption by Debian (de facto or de jure) of systemd as the one true init system. If it comes down to it I would prefer to drop Gnome than to make systemd mandatory for all of Debian's users and downstreams just because Gnome had introduced a hard dependency on systemd. Luckily this is all hypothetical. The only hypothetical situation that would result in dropping gnome is one where the TC enacts language barring dependencies on non-default init systems. In all other cases systemd remains in debian, and gnome can remain by using systemd. So, to lets take a step back from this hypothetical cliff by removing that idea from the discussion. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
Sergey B Kirpichev skirpic...@gmail.com writes: Are X-people indeed sacrifice portability, or there is something different (e.g. these dependencies are optional)? Speaking as the X server release manager, the systemd patches exist solely to provide for interoperation with systemd or other similar device management processes. None of them eliminate existing device management infrastructure at all. In effect, X takes the Debian position that patches which improve interoperabilty with a specific init system should be integrated. X is most definitely not going to ever require systemd. I think that any package which requires a specific init system is broken and I'd work to fix any that I depended on. Where is the list of problems for sysvinit we intend to solve? For X, the problem is running X as a user other than root, which should provide for increased system security as we'll be reducing the amount of root code substantially. Using the systemd mechanisms for sending new input devices to the X server solves one of the longstanding issues with non-root X. -- keith.pack...@intel.com pgpufbogLJ_GB.pgp Description: PGP signature
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
2014-01-31 Keith Packard kei...@keithp.com: Sergey B Kirpichev skirpic...@gmail.com writes: [...] Where is the list of problems for sysvinit we intend to solve? For X, the problem is running X as a user other than root, which should provide for increased system security as we'll be reducing the amount of root code substantially. Using the systemd mechanisms for sending new input devices to the X server solves one of the longstanding issues with non-root X. I was referring to that - of course X does not depend on systemd, but systemd provides features which make it possible to fix existing issues, that's why it makes sense to use it. Of course it does not exclude implementing that stuff in a different, non-systemd tool, but to my knowledge nobody has done that yet. Thank you for working on X and clarifying this! Matthias -- I welcome VSRE emails. See http://vsre.info/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
Matthias Klumpp matth...@tenstral.net writes: Of course it does not exclude implementing that stuff in a different, non-systemd tool, but to my knowledge nobody has done that yet. Exactly so. I have ideas on how this might work in a simpler and more general fashion, but people rarely listen to ideas without also seeing working code :-) -- keith.pack...@intel.com pgpihYFZRaSsF.pgp Description: PGP signature
Bug#727708: multiple init systems - formal resolution proposal
Le mardi 28 janvier 2014 à 19:34 +0200, Adrian Bunk a écrit : On Tue, Jan 28, 2014 at 01:24:12PM +0100, Olav Vitters wrote: On Tue, Jan 28, 2014 at 9:52 AM, Josselin Mouette j...@debian.org wrote: Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit : No. My question isn't about logind, but about using a user systemd session to supervise processes started by the session. IIRC both GNOME and KDE were mentioned to consider this feature. I wouldn't worry much about such features, at least not for jessie. They will most likely be fallbacks, and in the unlikely case they are at build time, we could always put the two binaries in the same package with dynamic detection, thus working around this requirement. Fallback is intended, so for near future you'd be ok. Longer term, I expect almost no maintenance to occur from GNOME side, so be prepared to handle the maintenance if nobody else does. ... The freeze for jessie will be in November 2014, so it will ship with GNOME 3.14 (or earlier). Am I reading your email correctly that can Debian assume that for the GNOME in jessie proper fallbacks will be in place, so that GNOME in jessie will work fine with init systems other than systemd? No, you are not. There are several features in systemd that GNOME uses. One of them is user sessions, for which there will indeed be a fallback in place. But it is not the only one. Cheers, -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
On Wed, Jan 29, 2014 at 10:05:22AM +0100, Josselin Mouette wrote: Le mardi 28 janvier 2014 à 19:34 +0200, Adrian Bunk a écrit : On Tue, Jan 28, 2014 at 01:24:12PM +0100, Olav Vitters wrote: On Tue, Jan 28, 2014 at 9:52 AM, Josselin Mouette j...@debian.org wrote: Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit : No. My question isn't about logind, but about using a user systemd session to supervise processes started by the session. IIRC both GNOME and KDE were mentioned to consider this feature. I wouldn't worry much about such features, at least not for jessie. They will most likely be fallbacks, and in the unlikely case they are at build time, we could always put the two binaries in the same package with dynamic detection, thus working around this requirement. Fallback is intended, so for near future you'd be ok. Longer term, I expect almost no maintenance to occur from GNOME side, so be prepared to handle the maintenance if nobody else does. ... The freeze for jessie will be in November 2014, so it will ship with GNOME 3.14 (or earlier). Am I reading your email correctly that can Debian assume that for the GNOME in jessie proper fallbacks will be in place, so that GNOME in jessie will work fine with init systems other than systemd? No, you are not. There are several features in systemd that GNOME uses. One of them is user sessions, for which there will indeed be a fallback in place. But it is not the only one. Can you provide a list of features without a fallback in place? Assuming jessie will support multiple init systems, why would GNOME need a dependency on systemd? I fully get the point that in such a scenario some GNOME packages would have a *Suggests* on systemd-sysv (no matter whether it's the default or not) - but do they really need a dependency? Part of what I am trying to understand is the scope of problems a theoretical scenario a new installation of jessie installs the default desktop GNOME and the default init system sysvinit [1] would produce. Would making any init system other than systemd the default for jessie automatically exclude GNOME from being considered as an option for the default desktop in jessie? Cheers, cu Adrian [1] or upstart or OpenRC -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
On Tue, Jan 28, 2014 at 10:50:00PM +0100, Olav Vitters wrote: ... Further, in my experience it was *way* more stable to either go for full systemd or always rely on the reduced functionality. The runtime detection of is systemd running as PID 1 was IMO not very stable (and that wasn't just GNOME components, others as well). Though that was under Mageia and later on Gentoo provided various patches to improve it (but no idea how good the current state is or if we regressed anywhere). I'd guess the main reason for this is that distributions usually support only one init system so the runtime detection rarely gets tested, and if Debian would support multiple init systems such issues would get sorted out quickly. Regards, Olav cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Le mercredi 29 janvier 2014 à 19:03 +0200, Adrian Bunk a écrit : No, you are not. There are several features in systemd that GNOME uses. One of them is user sessions, for which there will indeed be a fallback in place. But it is not the only one. Can you provide a list of features without a fallback in place? At least logind, timedated, hostnamed, localed, the boot control interfaces. With a very widespread level of failure depending on the unavailable interface. Assuming jessie will support multiple init systems, why would GNOME need a dependency on systemd? Because it needs logind. https://lists.debian.org/debian-ctte/2014/01/msg00360.html Would making any init system other than systemd the default for jessie automatically exclude GNOME from being considered as an option for the default desktop in jessie? There are solutions for a non-systemd init. They are technically wrong, but they are realistic (basically it means using logind v204). But there are no realistic solutions for having GNOME support multiple init systems in jessie. Cheers, -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
On Wed, Jan 29, 2014 at 06:41:11PM +0100, Josselin Mouette wrote: Le mercredi 29 janvier 2014 à 19:03 +0200, Adrian Bunk a écrit : ... Assuming jessie will support multiple init systems, why would GNOME need a dependency on systemd? Because it needs logind. https://lists.debian.org/debian-ctte/2014/01/msg00360.html ... You wrote there I also have to insist that GNOME 3.10+ *needs* a working logind even for basic functionality What Olav wrote sounds quite different. What *basic functionality* exactly is missing in GNOME 3.10 without logind? Note that I am not referring to bugs that are not yet sorted out like * Switch from consolekit to systemd-logind sessions. For some reason gnome-shell 3.10 unlocking fails with consolekit... 3 months ago in gdm3 - I am referring to basic functionality that is simply missing in GNOME 3.10 without logind. Cheers, cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Le mercredi 29 janvier 2014 à 20:00 +0200, Adrian Bunk a écrit : What *basic functionality* exactly is missing in GNOME 3.10 without logind? Note that I am not referring to bugs that are not yet sorted out like * Switch from consolekit to systemd-logind sessions. For some reason gnome-shell 3.10 unlocking fails with consolekit... 3 months ago in gdm3 - I am referring to basic functionality that is simply missing in GNOME 3.10 without logind. You have the answer to your own question above. Unlocking the screen sounds like pretty basic functionality. Gnome-shell uses GDM for screen locking, and GDM heavily relies on logind nowadays. There is fallback code that uses ConsoleKit, but it has been untested for several major releases, and now fails even for trivial things. Add to that the fact that ConsoleKit itself has been unmaintained for quite some time, making it unsuitable for a new stable release that needs maintenance for several more years -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
On Wed, Jan 29, 2014 at 07:17:29PM +0100, Josselin Mouette wrote: Le mercredi 29 janvier 2014 à 20:00 +0200, Adrian Bunk a écrit : What *basic functionality* exactly is missing in GNOME 3.10 without logind? Note that I am not referring to bugs that are not yet sorted out like * Switch from consolekit to systemd-logind sessions. For some reason gnome-shell 3.10 unlocking fails with consolekit... 3 months ago in gdm3 - I am referring to basic functionality that is simply missing in GNOME 3.10 without logind. You have the answer to your own question above. Unlocking the screen sounds like pretty basic functionality. Your statement was I also have to insist that GNOME 3.10+ *needs* a working logind even for basic functionality Are you saying that there are only some bugs to get sorted out for using GNOME 3.10 without logind, or is there a fundamental technical reason why some *basic functionality* (which?) cannot be made working in GNOME 3.10 without logind? ... Add to that the fact that ConsoleKit itself has been unmaintained for quite some time, making it unsuitable for a new stable release that needs maintenance for several more years Debian is anyway not providing much maintenance apart from security updates for stable, so there is no real problem here for jessie. And for security fixes, companies like Red Hat are anyway committed to provide these for ConsoleKit for their products until around 5 years *after* Debian will have dropped security support for jessie.[1] cu Adrian [1] the announced End of Extended Life Cycle for Red Hat Enterprise Linux 6 is Q4 2023 -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Le mercredi 29 janvier 2014 à 20:43 +0200, Adrian Bunk a écrit : You have the answer to your own question above. Unlocking the screen sounds like pretty basic functionality. Your statement was I also have to insist that GNOME 3.10+ *needs* a working logind even for basic functionality My bad. I was under the impression you wanted a serious discussion. Sorry for contributing to the noise, everyone. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Adrian Bunk b...@stusta.de writes: On Wed, Jan 29, 2014 at 07:17:29PM +0100, Josselin Mouette wrote: Le mercredi 29 janvier 2014 à 20:00 +0200, Adrian Bunk a écrit : What *basic functionality* exactly is missing in GNOME 3.10 without logind? Note that I am not referring to bugs that are not yet sorted out like * Switch from consolekit to systemd-logind sessions. For some reason gnome-shell 3.10 unlocking fails with consolekit... 3 months ago in gdm3 - I am referring to basic functionality that is simply missing in GNOME 3.10 without logind. You have the answer to your own question above. Unlocking the screen sounds like pretty basic functionality. Your statement was I also have to insist that GNOME 3.10+ *needs* a working logind even for basic functionality Are you saying that there are only some bugs to get sorted out for using GNOME 3.10 without logind, or is there a fundamental technical reason why some *basic functionality* (which?) cannot be made working in GNOME 3.10 without logind? I'm still wondering if maybe there's just a communication failure here, so let me try one more round. My understanding of what Josselin is saying is that GNOME's ConsoleKit support is effectively unmaintained and unsupported upstream, as is ConsoleKit itself. The consequences of that are starting to show in a variety of unfixed bugs. In one sense, that's just bugs to be sorted out. However, they're upstream bugs in code that upstream appears to no longer be interested in supporting, and they're bugs that the Debian GNOME maintainers are unenthused about trying to fix, since that would effectively require taking over maintenance of the ConsoleKit code upstream. (Not to mention that the logind code path appears to be technically much better and have a much stronger future, so it's hard to get motivated to work on the ConsoleKit code.) In other words, they're bugs with no resources currently assigned. Note that things like screen lock have security implications, so the jessie stable lifetime *is* important for this code. Maintaining it properly would require confidence that we would be able to identify and fix security issues in the GNOME code and in ConsoleKit through the jessie supported lifecycle. Obviously, if resources appear, that changes the situation, but I think the GNOME maintainers are understandably wary of such approaches as someone taking a week and fixing all the currently known bugs and then moving on to other things, since their expectation is that, given the situation, new bugs and new issues will continue to arise. The code really needs an ongoing maintainer with a good upstream relationship who can get the fixes and support incorporated upstream for it to remain viable. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
On Wed, Jan 29, 2014 at 11:27:53AM -0800, Russ Allbery wrote: Adrian Bunk b...@stusta.de writes: On Wed, Jan 29, 2014 at 07:17:29PM +0100, Josselin Mouette wrote: Le mercredi 29 janvier 2014 à 20:00 +0200, Adrian Bunk a écrit : What *basic functionality* exactly is missing in GNOME 3.10 without logind? Note that I am not referring to bugs that are not yet sorted out like * Switch from consolekit to systemd-logind sessions. For some reason gnome-shell 3.10 unlocking fails with consolekit... 3 months ago in gdm3 - I am referring to basic functionality that is simply missing in GNOME 3.10 without logind. You have the answer to your own question above. Unlocking the screen sounds like pretty basic functionality. Your statement was I also have to insist that GNOME 3.10+ *needs* a working logind even for basic functionality Are you saying that there are only some bugs to get sorted out for using GNOME 3.10 without logind, or is there a fundamental technical reason why some *basic functionality* (which?) cannot be made working in GNOME 3.10 without logind? I'm still wondering if maybe there's just a communication failure here, so let me try one more round. My understanding of what Josselin is saying is that GNOME's ConsoleKit support is effectively unmaintained and unsupported upstream, as is ConsoleKit itself. The consequences of that are starting to show in a variety of unfixed bugs. ... No, Josselin was making the technical claim that GNOME 3.10 would need a working logind even for basic functionality. So if it is possible to get the basic functionality of GNOME 3.10 without a working logind, his claim is just plain wrong. And when I was asking him for the technical details that would back up such a strong claim, he was not able to deliver. And that does matter a lot, since such claims seem to be the basis of all these GNOME in jessie needs systemd or with multiple init systems, GNOME will need a dependency on systemd (and Josselin even expects an exception from the release managers for that if the TC decision would not allow such a dependency [1]). I do fully acknowledge that there are issues with ConsoleKit being unmaintained and many non-systemd codepath in GNOME being unmaintained and with GNOME missing some non-basic functionality without systemd. But claims that even basic functionality in GNOME in jessie could not work without logind might just be FUD. The TC can rule that systemd will be the default for jessie and that dependencies on systemd will be OK if a maintainer wishes do add them, but such a decision should be based on facts and not on unproven GNOME needs it claims. cu Adrian [1] https://lists.debian.org/debian-ctte/2014/01/msg00460.html -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
2014-01-29 Adrian Bunk b...@stusta.de: [...] I do fully acknowledge that there are issues with ConsoleKit being unmaintained and many non-systemd codepath in GNOME being unmaintained and with GNOME missing some non-basic functionality without systemd. But claims that even basic functionality in GNOME in jessie could not work without logind might just be FUD. The TC can rule that systemd will be the default for jessie and that dependencies on systemd will be OK if a maintainer wishes do add them, but such a decision should be based on facts and not on unproven GNOME needs it claims. No, Josselin is right: GNOME *does not* work without services provided by systemd. He never said that - given some amount of work - it can't be made working. But given the limited resources of the GNOME team, I can fully understand why they don't want to make the other solutions work (e.g. by taking over ConsoleKit maintenance). So, Joss' statement is correct. Also, have in mind that logind provides the basis for some additional features (e.g. real multiseat-support, sane closing of applications on logout, shutdown inhibitions etc.) and that systemd/logind is required for using Wayland, and GNOME is definitively going that road. Also, there are plans to make systemd --user manage a GNOME session, so the gnome-session codepath wil bitrot soon as well. And even on KDE we are evaluating that option[1], so it's not just GNOME going that way. Cheers, Matthias [1] Fallbacks in place, but I don't know anyone who likes working on startkde... -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Matthias Klumpp dixit: No, Josselin is right: GNOME *does not* work without services provided by systemd. He never said that - given some amount of work - it can't Hum, we can always add “remove GNOME (3) from Debian” to the list of GR or TC points to consider (this *has* been suggested earlier, even)… and given that MATE seems to have picked up the market of GNOME… Also, have in mind that logind provides the basis for some additional features (e.g. real multiseat-support, sane closing of applications on logout, shutdown inhibitions etc.) and that systemd/logind is required for using Wayland, and GNOME is definitively going that road. Also, This is more of a threat than a promise. gnome-session codepath wil bitrot soon as well. And even on KDE we are evaluating that option[1], so it's not just GNOME going that way. As long as it’s still evaluating… the evaluation can result in “let’s do a more sane thing, after all GNOME got kicked off Debian for requiring systemd”. I *still* don’t see a problem with keeping sysvinit with sysv-rc, which I’m not overly fond of but which is still better than the alternatives – and all packages have sysvinit scripts already *anyway* so there is no added maintenance burden except for those who do wish to support other inits, which, in turn, can run the existing initscripts. My favourite option would thus be to keep sysvinit/sysv-rc forever, keep it as default for jessie, and do not permit any package to depend on an init implementation, but allow packages to degrade if the currently active init (be it the default init or not) does not support everything needed (i.e. no “allow degrade iff a default init is chosen” or “allow degrade iff a non-default init is chosen”). bye, //mirabilos -- 13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good guy. But he's always right! In every fsckin' situation, he's right. Even with his deeply perverted taste in software and borked ambition towards broken OSes - in the end, he's damn right about it :(! […] works in mksh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
On Wed, Jan 29, 2014 at 09:24:16PM +0100, Matthias Klumpp wrote: 2014-01-29 Adrian Bunk b...@stusta.de: [...] I do fully acknowledge that there are issues with ConsoleKit being unmaintained and many non-systemd codepath in GNOME being unmaintained and with GNOME missing some non-basic functionality without systemd. But claims that even basic functionality in GNOME in jessie could not work without logind might just be FUD. The TC can rule that systemd will be the default for jessie and that dependencies on systemd will be OK if a maintainer wishes do add them, but such a decision should be based on facts and not on unproven GNOME needs it claims. No, Josselin is right: GNOME *does not* work without services provided by systemd. How did you verify that this claim you are making here is actually true? He never said that - given some amount of work - it can't be made working. But given the limited resources of the GNOME team, I can fully understand why they don't want to make the other solutions work (e.g. by taking over ConsoleKit maintenance). So, Joss' statement is correct. ... No, it is not correct. Note that Josselin's statement [1] I also have to insist that GNOME 3.10+ *needs* a working logind even for basic functionality, and that starting with v205, logind *needs* systemd as PID 1. You might disagree with the implementation details that lead to this situation, but you should not expect either of these facts to change before jessie. does not mention any resource problem.[2] Neither does his statement contain any mentioning of ConsoleKit maintainership - and taking over ConsoleKit maintainership would anyway not fix the alleged GNOME 3.10+ *needs* a working logind. He plainly claims that logind would be required for GNOME. And you are wrong when you claim He never said that it can't be made working. In fact, what Josselin insists on there is that starting with GNOME 3.10 no version of GNOME before jessie will be able to provide even basic functionality without logind. Cheers, Matthias ... cu Adrian [1] https://lists.debian.org/debian-ctte/2014/01/msg00360.html [2] in which case a call for people working on that would be more appropriate -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Adrian Bunk b...@stusta.de writes: On Wed, Jan 29, 2014 at 11:27:53AM -0800, Russ Allbery wrote: I'm still wondering if maybe there's just a communication failure here, so let me try one more round. My understanding of what Josselin is saying is that GNOME's ConsoleKit support is effectively unmaintained and unsupported upstream, as is ConsoleKit itself. The consequences of that are starting to show in a variety of unfixed bugs. ... No, Josselin was making the technical claim that GNOME 3.10 would need a working logind even for basic functionality. So if it is possible to get the basic functionality of GNOME 3.10 without a working logind, his claim is just plain wrong. And when I was asking him for the technical details that would back up such a strong claim, he was not able to deliver. He delivered exactly what you asked for, and you then deleted his response and claimed he didn't provide it. Then you did the same thing to me. It looks like Josselin's response to you was the correct one, and I will now follow his lead, do what I should have done a while back, and stop responding to your email messages on this topic, since I don't believe you're discussing in good faith. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
On Wed, Jan 29, 2014 at 08:45:32PM +, Thorsten Glaser wrote: Matthias Klumpp dixit: No, Josselin is right: GNOME *does not* work without services provided by systemd. He never said that - given some amount of work - it can't Hum, we can always add “remove GNOME (3) from Debian” to the list of GR or TC points to consider (this *has* been suggested earlier, even)… and given that MATE seems to have picked up the market of GNOME… As agreed privately, please don't talk about GNOME. Your suggestions don't make much sense and you don't know what you're talking about anyway. Your continued characterization of GNOME (e.g. threat) while knowing nothing is quite sad. Apologies to the rest reading this… -- Regards, Olav -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Hello, On Wed, 29 Jan 2014 19:17:29 +0100 Josselin Mouette j...@debian.org wrote: Gnome-shell uses GDM for screen locking, and GDM heavily relies on logind nowadays. There is fallback code that uses ConsoleKit, but it has been untested for several major releases, and now fails even for trivial things. Add to that the fact that ConsoleKit itself has been unmaintained for quite some time, making it unsuitable for a new stable release that needs maintenance for several more years That only confirms the fact GNOME developers can't even keep their code working, not even speaking about testing its interoperability with most common environments. That doesn't create a good reputation, you know. -- Cheers, Andrew signature.asc Description: PGP signature
Bug#727708: multiple init systems - formal resolution proposal
On Wed, Jan 29, 2014 at 11:54:11PM +0100, Andrew Shadura wrote: On Wed, 29 Jan 2014 19:17:29 +0100 Josselin Mouette j...@debian.org wrote: Gnome-shell uses GDM for screen locking, and GDM heavily relies on logind nowadays. There is fallback code that uses ConsoleKit, but it has been untested for several major releases, and now fails even for trivial things. Add to that the fact that ConsoleKit itself has been unmaintained for quite some time, making it unsuitable for a new stable release that needs maintenance for several more years That only confirms the fact GNOME developers can't even keep their code working, not even speaking about testing its interoperability with most common environments. That doesn't create a good reputation, you know. Almost all of our developers are either using systemd, or they're using something which provides logind (Ubuntu). Even Gentoo has started depending on systemd (thus logind, etc) for GNOME. In short: for the most common environment, GNOME is damn stable and very well tested. -- Regards, Olav -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
On 30 January 2014 09:54, Andrew Shadura and...@shadura.me wrote: Hello, On Wed, 29 Jan 2014 19:17:29 +0100 Josselin Mouette j...@debian.org wrote: Gnome-shell uses GDM for screen locking, and GDM heavily relies on logind nowadays. There is fallback code that uses ConsoleKit, but it has been untested for several major releases, and now fails even for trivial things. Add to that the fact that ConsoleKit itself has been unmaintained for quite some time, making it unsuitable for a new stable release that needs maintenance for several more years That only confirms the fact GNOME developers can't even keep their code working, not even speaking about testing its interoperability with most common environments. That doesn't create a good reputation, you know. Why do you expect GNOME developers to maintain support for ConsoleKit, when it's been deprecated and unmaintained for several years? It's not the responsibility of the GNOME developers to pick up maintenance of ConsoleKit and to suggest that not doing this is representative of their quality as developers is borderline offensive. GNOME developers do keep their code working, against what they've stated they will support. That happens to be logind. (Apologies if I'm not replying to this bug correctly as it's my first time emailing against a Debian bug) Regards, James.
Bug#727708: multiple init systems - formal resolution proposal
Andrew Shadura and...@shadura.me writes: Josselin Mouette j...@debian.org wrote: Gnome-shell uses GDM for screen locking, and GDM heavily relies on logind nowadays. There is fallback code that uses ConsoleKit, but it has been untested for several major releases, and now fails even for trivial things. Add to that the fact that ConsoleKit itself has been unmaintained for quite some time, making it unsuitable for a new stable release that needs maintenance for several more years That only confirms the fact GNOME developers can't even keep their code working, not even speaking about testing its interoperability with most common environments. That doesn't create a good reputation, you know. The point of this discussion is to determine the set of constraints we have around dependencies on either init systems or components closely tied to init systems. GNOME's reputation for portability or code stability, for good or for ill, is not directly relevant; what's relevant is whether the software works or does not work in particular configurations, and what the implications are for package dependencies within Debian. Whether or not GNOME itself is stable, portable, or to your liking is only relevant if the project believes it is so unstable or so uninteresting that we're not going to ship it in jessie, and I don't believe there is any realistic chance we would pick that option. Given that, your opinions about the quality of GNOME upstream development don't seem relevant to the problem we're trying to resolve. If you don't like the software, don't use it. And please don't hold opinions about the proper packaging of software you don't like and don't believe is well-written! That's just intensely irritating and comes across as malicious sniping. Let the people who are interested in making the software work figure out what that entails. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Re: Bug#727708: multiple init systems - formal resolution proposal
This sounds like a good solution, since MATE is the gnome we all knew, and the Gnome of today is a different beast entirely (though it gets to keep the name). :: Hum, we can always add “remove GNOME (3) from Debian” to the list of GR or TC points to consider (this *has* been suggested earlier, even)… and given that MATE seems to have picked up the market of GNOME… This is more of a threat than a promise. There are alot of those from a certain crowd. They use the carrot and the stick approach. The proper free/open approach is just the carrot and let people decide and respect them. Not cattle pen them and run them to wherever one wishes. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Re: Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
If you don't like the software, don't use it. Absolutely. But that is not really an option that is to be afforded to all of us if the systemd guys successfully have their way with linux. It would be nice if they afforded us such a freedom, but their statements and their actions suggest that this would be a one way street: They convince as many pieces of the software stack as possible to depend on systemd, and we can go use an embedded system or something (yes that's a quote from one of the systemders) if we don't like it. When they came here their proposal was to remove all other init systems from Debian, and force everyone to use systemd. They are here to conquer. In time the statement would read: If you don't like systemd, don't use linux - get a mac or something *SNCR* They have conquered a good number of other distributions, now it is time to bring Debian, too, into the fold. Given that, your opinions about the quality of GNOME upstream development don't seem relevant to the problem we're trying to resolve. If you don't like the software, don't use it. And please don't hold opinions about the proper packaging of software you don't like and don't believe is well-written! That's just intensely irritating and comes across as malicious sniping. Let the people who are interested in making the software work figure out what that entails. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Re: Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
2014-01-30 ChaosEsque Team chaosesquet...@yahoo.com: [bullshit] Wasn't there some kind of a ban applied here? I am confused. Cheers, Matthias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit : Adrian Bunk b...@stusta.de writes: You are forgetting the best technical solution, which is what gnome-session is actually implementing at the moment: session_tracking=systemd (with fallback to ConsoleKit) [1] No. My question isn't about logind, but about using a user systemd session to supervise processes started by the session. IIRC both GNOME and KDE were mentioned to consider this feature. I wouldn’t worry much about such features, at least not for jessie. They will most likely be fallbacks, and in the unlikely case they are at build time, we could always put the two binaries in the same package with dynamic detection, thus working around this requirement. The real problem is logind. The requirement proposed by Ian is not implementable: http://lists.debian.org/1390155797.29928.17.camel@tomoe -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
On Tue, Jan 28, 2014 at 9:52 AM, Josselin Mouette j...@debian.org wrote: Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit : No. My question isn't about logind, but about using a user systemd session to supervise processes started by the session. IIRC both GNOME and KDE were mentioned to consider this feature. I wouldn't worry much about such features, at least not for jessie. They will most likely be fallbacks, and in the unlikely case they are at build time, we could always put the two binaries in the same package with dynamic detection, thus working around this requirement. Fallback is intended, so for near future you'd be ok. Longer term, I expect almost no maintenance to occur from GNOME side, so be prepared to handle the maintenance if nobody else does. Though I guess it'll be like ConsoleKit case: I'm warning, but nothing happens :-( The real problem is logind. The requirement proposed by Ian is not implementable: http://lists.debian.org/1390155797.29928.17.camel@tomoe IMO other init systems should provide the interfaces which GNOME requires. It is not up to GNOME to provide these. That or takeup ConsoleKit maintenance (or logind alternative), but despite warning about and requesting this in January 2012, not much has happened. So I think the proposal should be turned around: Init systems should ensure that they meet the changing requirements of the rest of the stack. Aside from this we're open to discuss things with distributions. For logind case I approached various times (obviously not knowing Debian) and we warned and requested feedback. Initially via our distributor-list, but also reached out to debian-devel. Any practical answer and/or discussion is very welcome. The lack of any answer means we'll continue to do what we think is best. To be clear: Any answer like it should just work across init systems for me is not a practical answer as it ignores all the issues we're facing with this. That said, we don't rely on systemd. If there's functionality that we really want, need or makes our lives much easier, then I don't see how you can demand us to do double or triple work. The burden should be placed correctly, not with us. I'm quite saddened by lack of response to e.g. ConsoleKit/logind btw, it's been 2 years already!! Regards, Olav (GNOME release team dude for the people who don't know) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Michael Gilbert dixit: Why not avoid impeding progress and just let gnome do what it needs to work the way it wants, which would involve depending on the right Excuse me, why is GNOME, specifically, being allowed to “do what it wants”, in this case? Imagine other software with a more-or-less legitimate dependency on, meh idk, upstart for example. No. bye, //mirabilos -- Natureshadow Warum ist MirWebseite eigentlich so cool? mirabilos weil ich ich sie geschrieben habe Natureshadow Hast du sie geschrieben oder geforkt? mirabilos geschrieben, from scratch Natureshadow Ach, deshalb finde ich auch so selten Bugs dadrin. Irgendwie hast du Recht. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Olav Vitters dixit: IMO other init systems should provide the interfaces which GNOME requires. It is not up to GNOME to provide these. That or takeup There is a lot wrong with that statement. Imagine you’re working on/with a software FOO that is not yet packaged in Debian. Say it comes from the Macintosh world, so it does not build out-of-the-box. Common sense states that you need to port it to the Debian OS instead of Debian providing those Macintosh-specific APIs FOO uses. GNOME is not special. bye, //mirabilos -- 22:59⎜Vutral glaub ich termkit is kompliziert | glabe nicht das man damit schneller arbeitet | reizüberflutung │ wie windows │ alles evil zuviel bilder │ wie ein spiel | 23:00⎜Vutral die meisten raffen auch nicht mehr von windows | 23:01⎜Vutral bilderbücher sind ja auch nich wirklich verbreitet als erwachsenen literatur ‣ who needs GUIs thus? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
On Tue, Jan 28, 2014 at 01:24:12PM +0100, Olav Vitters wrote: On Tue, Jan 28, 2014 at 9:52 AM, Josselin Mouette j...@debian.org wrote: Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit : No. My question isn't about logind, but about using a user systemd session to supervise processes started by the session. IIRC both GNOME and KDE were mentioned to consider this feature. I wouldn't worry much about such features, at least not for jessie. They will most likely be fallbacks, and in the unlikely case they are at build time, we could always put the two binaries in the same package with dynamic detection, thus working around this requirement. Fallback is intended, so for near future you'd be ok. Longer term, I expect almost no maintenance to occur from GNOME side, so be prepared to handle the maintenance if nobody else does. ... The freeze for jessie will be in November 2014, so it will ship with GNOME 3.14 (or earlier). Am I reading your email correctly that can Debian assume that for the GNOME in jessie proper fallbacks will be in place, so that GNOME in jessie will work fine with init systems other than systemd? Regards, Olav (GNOME release team dude for the people who don't know) cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Ian Jackson writes (multiple init systems - formal resolution proposal): I hereby propose the following resolution: 1. Support for sysvinit is mandatory in jessie. 2. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Nothing outside of an init system's implementation may require a specific init system to be pid 1. Please send comments, or formal amendment proposals, by 2014-01-28 17:00 UTC. I will call a vote on some version(s) then. I withdraw this, as it's no longer needed. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
On Tue, Jan 28, 2014 at 07:34:56PM +0200, Adrian Bunk wrote: On Tue, Jan 28, 2014 at 01:24:12PM +0100, Olav Vitters wrote: On Tue, Jan 28, 2014 at 9:52 AM, Josselin Mouette j...@debian.org wrote: Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit : No. My question isn't about logind, but about using a user systemd session to supervise processes started by the session. IIRC both GNOME and KDE were mentioned to consider this feature. I wouldn't worry much about such features, at least not for jessie. They will most likely be fallbacks, and in the unlikely case they are at build time, we could always put the two binaries in the same package with dynamic detection, thus working around this requirement. Fallback is intended, so for near future you'd be ok. Longer term, I expect almost no maintenance to occur from GNOME side, so be prepared to handle the maintenance if nobody else does. ... The freeze for jessie will be in November 2014, so it will ship with GNOME 3.14 (or earlier). Am I reading your email correctly that can Debian assume that for the GNOME in jessie proper fallbacks will be in place, so that GNOME in jessie will work fine with init systems other than systemd? gnome-session will have a fallback for this in 3.14. Initially we assumed that gnome-session would go away totally, but seems even with systemd --user you'll still have a gnome-session around. It just does less in case of systemd. Note that I'm just talking about gnome-session. GNOME not under systemd does have it fair share of reduced functionality. Further, in my experience it was *way* more stable to either go for full systemd or always rely on the reduced functionality. The runtime detection of is systemd running as PID 1 was IMO not very stable (and that wasn't just GNOME components, others as well). Though that was under Mageia and later on Gentoo provided various patches to improve it (but no idea how good the current state is or if we regressed anywhere). -- Regards, Olav -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
On Tue, Jan 28, 2014 at 9:57 AM, Thorsten Glaser wrote: Michael Gilbert dixit: Why not avoid impeding progress and just let gnome do what it needs to work the way it wants, which would involve depending on the right Excuse me, why is GNOME, specifically, being allowed to “do what it wants”, in this case? gnome is simply an example, which makes sense to talk about given its apparent direction toward being systemd-only. Why exactly would it be harmful for the gnome island to be a systemd world? Imagine other software with a more-or-less legitimate dependency on, meh idk, upstart for example. I don't see any problem with that either. If someone were interested in creating upstartwm, why get in their way? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Ian Jackson ijack...@chiark.greenend.org.uk writes: I hereby propose the following resolution: 1. Support for sysvinit is mandatory in jessie. 2. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Nothing outside of an init system's implementation may require a specific init system to be pid 1. I'm not comfortable with a mandate that packages may not require a specific init system as pid 1. While the case that has been discussed repeatedly recently involves GNOME and systemd, this text as written at least begs the question of what defines outside of an init system. I understand and sympathize strongly with what you're trying to accomplish here, I'm just not convinced (yet?) that this is the right way to proceed. Bdale pgpXokgj6ploA.pgp Description: PGP signature
Bug#727708: multiple init systems - formal resolution proposal
Hi, Ian Jackson ijack...@chiark.greenend.org.uk writes: Ian Jackson writes (Bug#727708: multiple init systems - formal resolution proposal): I hereby propose the following resolution: 1. Support for sysvinit is mandatory in jessie. I hereby propose and accept an amendment to add a new rubric paragraph 0, and I also propose and do NOT accept an amendment to delete paragraph 2, so as to result in the following proposal: == both versions == 0. We exercise our power to set policy, Constitution 6.1.1: 6.1.1 states In each case the usual maintainer of the relevant software or documentation makes decisions initially, however; see 6.3(5).. So in this case the Policy editors should make the decision initially. The ctte can then override them, but would require a 3:1 majority (unless the Policy editors defer the issue under 6.1.3). 1. Support for sysvinit is mandatory in jessie. This is a should currently (Policy 9.3.2). Do you plan to change this to a must? Would git-daemon-run violate this? Note that git-daemon-run provides sysvinit integration. == version multiple only == 2. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Nothing outside of an init system's implementation may require a specific init system to be pid 1. It's unclear if reduced functionality (or in the extreme case no functionality) would satisfy this. Would a gnome-session-systemd package that requires systemd violate this (if gnome-session is also available)? If yes, what is the reason for forbidding people from trying out new things? Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
On Mon, Jan 27, 2014 at 11:59 AM, Ian Jackson wrote: 2. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Nothing outside of an init system's implementation may require a specific init system to be pid 1. I think the push back you're seeing about this is because the second sentence imposes a fairly significant constraint on the project. Say gnome ultimately requires systemd, and something else in the meantime happens to be pid 1, that sentence really gets in the way. Why not avoid impeding progress and just let gnome do what it needs to work the way it wants, which would involve depending on the right stuff to make systemd its pid 1? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
On Tue, Jan 28, 2014 at 12:18:09AM +0100, Ansgar Burchardt wrote: ... == version multiple only == 2. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Nothing outside of an init system's implementation may require a specific init system to be pid 1. It's unclear if reduced functionality (or in the extreme case no functionality) would satisfy this. Would a gnome-session-systemd package that requires systemd violate this (if gnome-session is also available)? ... You are forgetting the best technical solution, which is what gnome-session is actually implementing at the moment: session_tracking=systemd (with fallback to ConsoleKit) [1] Ansgar cu Adrian [1] copied from the gnome-session configure.ac -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
On Mon, Jan 27, 2014 at 08:54:13PM -0500, Michael Gilbert wrote: On Mon, Jan 27, 2014 at 11:59 AM, Ian Jackson wrote: 2. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Nothing outside of an init system's implementation may require a specific init system to be pid 1. I think the push back you're seeing about this is because the second sentence imposes a fairly significant constraint on the project. Say gnome ultimately requires systemd, and something else in the meantime happens to be pid 1, that sentence really gets in the way. Why not avoid impeding progress and just let gnome do what it needs to work the way it wants, which would involve depending on the right stuff to make systemd its pid 1? Claiming that the scope would be limited to GNOME is already factually incorrect as of today in experimental. NetworkManager and PolicyKit can be compiled with support for logind, or with support for ConsoleKit+upower. In experimental, they do support only logind. That's an example where such a policy that requires either a non-systemd logind replacement, or runtime detection of logind and sensible fallbacks like in gnome-session, has to be in place to secure that supporting multiple init systems is actually true in practice. [1] Best wishes, Mike cu Adrian [1] That's ignoring the possibility that a non-systemd logind replacement with sufficient functionality for all software following the latest logind features might show up one day - but without such a policy such a non-systemd logind would not be a prerequisite for these packages to move from experimental to unstable and testing. -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
On Tue, Jan 28, 2014 at 08:40:01AM +0200, Adrian Bunk wrote: ... [1] That's ignoring the possibility that a non-systemd logind replacement with sufficient functionality for all software following the latest logind features might show up one day - but ,,, Please ignore this part of [1] - I botched proof-reading my email after rewriting it. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
❦ 28 janvier 2014 07:23 CET, Adrian Bunk b...@stusta.de : You are forgetting the best technical solution, which is what gnome-session is actually implementing at the moment: session_tracking=systemd (with fallback to ConsoleKit) [1] Sure, the best technical solution is to rely on an unmaintained component. -- Write and test a big program in small pieces. - The Elements of Programming Style (Kernighan Plauger) signature.asc Description: PGP signature
Bug#727708: multiple init systems - formal resolution proposal
Adrian Bunk b...@stusta.de writes: On Tue, Jan 28, 2014 at 12:18:09AM +0100, Ansgar Burchardt wrote: ... == version multiple only == 2. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Nothing outside of an init system's implementation may require a specific init system to be pid 1. It's unclear if reduced functionality (or in the extreme case no functionality) would satisfy this. Would a gnome-session-systemd package that requires systemd violate this (if gnome-session is also available)? ... You are forgetting the best technical solution, which is what gnome-session is actually implementing at the moment: session_tracking=systemd (with fallback to ConsoleKit) [1] No. My question isn't about logind, but about using a user systemd session to supervise processes started by the session. IIRC both GNOME and KDE were mentioned to consider this feature. Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
I hereby propose the following resolution: 1. Support for sysvinit is mandatory in jessie. 2. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Nothing outside of an init system's implementation may require a specific init system to be pid 1. Please send comments, or formal amendment proposals, by 2014-01-28 17:00 UTC. I will call a vote on some version(s) then. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Ian Jackson writes (multiple init systems - formal resolution proposal): I hereby propose the following resolution: 1. Support for sysvinit is mandatory in jessie. 2. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Nothing outside of an init system's implementation may require a specific init system to be pid 1. Please send comments, or formal amendment proposals, by 2014-01-28 17:00 UTC. I will call a vote on some version(s) then. I would like to make a procedural comment here. I think it is rather wrong to be voting on the interlinked questions of support for multiple systems, and what the default should be, in separate resolutions. TC members should have the ability to rank only X against X and others in a different order to only Y vs Y and others. However, Bdale's approach has meant that this is the only way forward for me. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Ian Jackson ijack...@chiark.greenend.org.uk writes: I hereby propose the following resolution: 1. Support for sysvinit is mandatory in jessie. I agree with this in principle, but I think this loses quite a bit of nuance and is likely, phrased in that way, to be used as a stick to beat maintainers with in ways that aren't helpful. I'd rather wait until we decide what the default will be and then try to work out exactly what sort of sysvinit support we want given that. The details of any future support plan are going to vary. 2. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Nothing outside of an init system's implementation may require a specific init system to be pid 1. I will probably be voting against this. I don't think it makes sense to constrain what we put in the archive in quite this way, as was previously discussed on this bug. If some piece of software has no upstream support for other init systems, I would rather have that software packaged for the init system that it does support than not permitted to be in Debian at all. Major packages or packages with higher than optional priority are possibly another matter, as possibly are packages which work fine with other init systems but whose maintainers don't want to add support, but I think making this sort of flat statement is too constraining. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Russ Allbery writes (Bug#727708: multiple init systems - formal resolution proposal): Ian Jackson ijack...@chiark.greenend.org.uk writes: I hereby propose the following resolution: 1. Support for sysvinit is mandatory in jessie. I agree with this in principle, but I think this loses quite a bit of nuance and is likely, phrased in that way, to be used as a stick to beat maintainers with in ways that aren't helpful. I'd rather wait until we decide what the default will be and then try to work out exactly what sort of sysvinit support we want given that. The details of any future support plan are going to vary. I am not willing to wait. I think it is too important to make this clear right away. Otherwise the main default decision risks a stampede to create facts on the ground. 2. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Nothing outside of an init system's implementation may require a specific init system to be pid 1. I will probably be voting against this. [...] I take it then that you have no wording changes which would change your mind. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Le lundi 27 janvier 2014 à 16:59 +, Ian Jackson a écrit : I hereby propose the following resolution: 1. Support for sysvinit is mandatory in jessie. 2. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Nothing outside of an init system's implementation may require a specific init system to be pid 1. Since this resolution would override the will of each maintainer to make his package depend on whatever init system the software depends on, it requires a 3:1 majority according to Constitution §6.1.4. -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Josselin Mouette writes (Bug#727708: multiple init systems - formal resolution proposal): Le lundi 27 janvier 2014 à 16:59 +, Ian Jackson a écrit : I hereby propose the following resolution: 1. Support for sysvinit is mandatory in jessie. 2. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Nothing outside of an init system's implementation may require a specific init system to be pid 1. Since this resolution would override the will of each maintainer to make his package depend on whatever init system the software depends on, it requires a 3:1 majority according to Constitution §6.1.4. No, because this is exercising our power to set technical policy, 6.1.1. I will send an updated version. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Le lundi 27 janvier 2014 à 17:48 +, Ian Jackson a écrit : Josselin Mouette writes (Bug#727708: multiple init systems - formal resolution proposal): Since this resolution would override the will of each maintainer to make his package depend on whatever init system the software depends on, it requires a 3:1 majority according to Constitution §6.1.4. No, because this is exercising our power to set technical policy, 6.1.1. I will send an updated version. Oh well, you can of course add non-implementable clauses to the policy. But I trust the release team to accept the necessary exceptions for the system to actually work. In which case, if you wish to override them at that point, it will require a 3:1 majority. kthxbye, -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Ian Jackson ijack...@chiark.greenend.org.uk writes: Russ Allbery writes: 2. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Nothing outside of an init system's implementation may require a specific init system to be pid 1. I will probably be voting against this. [...] I take it then that you have no wording changes which would change your mind. Not on point 2, no. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal
Ian Jackson writes (Bug#727708: multiple init systems - formal resolution proposal): I hereby propose the following resolution: 1. Support for sysvinit is mandatory in jessie. I hereby propose and accept an amendment to add a new rubric paragraph 0, and I also propose and do NOT accept an amendment to delete paragraph 2, so as to result in the following proposal: == both versions == 0. We exercise our power to set policy, Constitution 6.1.1: 1. Support for sysvinit is mandatory in jessie. == version multiple only == 2. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Nothing outside of an init system's implementation may require a specific init system to be pid 1. == resolution proposal ends == I'm expecting, although I have left it unsaid, that the policy maintainers would implement this by writing suitable specific wording in the policy manual. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
