Bug#727708: Init system resolution open questions
]] Adrian Bunk I already gave my hypothetical udev gets a hard dependency on systemd as init system worst case. To make the worst case even worse, assume a new upstream version of systemd with this change gets released 2 weeks before the jessie freeze, and gets uploaded into unstable immediately.[1] Then the systemd maintainer (i.e. me and the rest of the team) should be bopped on the head. I'd appreciate if your hypothetical scenarios aren't «let's assume that everyone are bonkers and do crazy stuff», since well, if they are, we need to fix that. The problem then isn't that they're uploading packages which are not appropriate for the archive, it's that they don't understand why that is a problem. You can't regulate «don't be crazy», since if people want to, or don't understand what crazy means they will route around such a decision using technicalities. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Init system resolution open questions
Adrian Bunk b...@stusta.de writes: On Sat, Jan 18, 2014 at 08:49:48PM -0800, Russ Allbery wrote: Adrian Bunk b...@stusta.de writes: The problem is different - with systemd there is a fast process going on where frequently-used configurations stop working without systemd. Are you only thinking of logind with desktop environments here, or are you thinking of something else? I don't think this process is actually very fast (we've been arguing about this for at least a year), and I think you're overstating this case, but maybe I missed something. If you're just referring to GNOME, one desktop environment currently switched over doesn't strike me as very fast, and whether that's the path forward for that desktop environment for jessie is to a large extent what we're debating here. I am not only talking about GNOME, or only about logind. I already gave my hypothetical udev gets a hard dependency on systemd as init system worst case. To make the worst case even worse, assume a new upstream version of systemd with this change gets released 2 weeks before the jessie freeze, and gets uploaded into unstable immediately.[1] [...] I'm really not interested in discussing hypotheticals. You said that there was a fast process towards frequently-used configurations that don't work without systemd. I'm interested in concrete examples of this. If all you have are hypotheticals, I question the accuracy of that statement and the usefulness of discussing them right now. My point is that the CTTE decision has to cover such cases, to avoid in this hypothetical even worse worst case huge flamewars and possibly even a GR during the freeze delaying the release of jessie. I don't agree. I don't think the TC decision needs to cover various hypotheticals, only likely scenarios that we can reasonably forsee and that we have some concrete reason to believe that the relevant maintainers won't be able to resolve them themselves. The best way to avoid long-term major forks is when the Debian maintainers make it clear to upstream that e.g. ConsoleKit codepaths shouldn't be dropped upstream since that would make it harder for Debian's non-Linux ports. Sure. But upstream is also allowed to not care about Debian's non-Linux ports, just as no one requires Debian maintainers to do any work that they don't want to do. We're all volunteers here. And in the cases where it doesn't work, it is very likely that supporting any non-systemd init system will imply that Debian will have to maintain or at least adopt long-term major forks. For that package, indeed. The point here is that there are three possible outcomes to upstream making their software less portable (assuming we can't convince them to reverse that decision): we drop the software entirely, we fork it to add portability, or we make it available only on the architectures and configurations that upstream supports. All three of those are options, and Debian will continue to use all three approaches depending on the situation. Sometimes, we'll even use combinations of several approaches there. It doesn't do any good to try to make some general rule about what approach we're going to take in advance, since which of those three options is the most appropriate depends entirely on the specific circumstances. No, I am not assuming bad faith. But there will be cases where the goals like 1. give users of systemd under Linux the best possible experience 2. support non-Linux ports 3. support other init systems conflict. What is better depends on which goal has a higher priority for you. There shoud be a general project direction that clearly defines which of these two goals has a higher priority for Debian, not half of the packages going into one direction and the other half into the other direction. I don't even agree with this. I think it's perfectly reasonable for some Debian contributors to choose to put more of their time into giving users of the default init system on Linux the best possible experience, and other Debian contributors to concentrate on supporting non-Linux ports or other init systems, depending on what that individual maintainer feels is the most important and what they want to spend time on. The point of this bug is to choose a default init system. With most of those choices come obvious benefits if we add native support for that init system to our packaging. That doesn't mean anyone is obligated to do so. It does mean that they shouldn't stand in the way of other people doing so. Some packages are going to be converted to native support for the default init system quickly, some slowly, and different contributors will use different approaches. That's fine. The following are two quite different options: 1. support multiple init systems since the non-Linux ports are core functionality of Debian 2. support multiple init systems, without considering the non-Linux ports to be core functionality of
Bug#727708: Init system resolution open questions
On Sun, Jan 19, 2014 at 11:00:01AM +0100, Tollef Fog Heen wrote: ]] Adrian Bunk I already gave my hypothetical udev gets a hard dependency on systemd as init system worst case. To make the worst case even worse, assume a new upstream version of systemd with this change gets released 2 weeks before the jessie freeze, and gets uploaded into unstable immediately.[1] Then the systemd maintainer (i.e. me and the rest of the team) should be bopped on the head. I'd appreciate if your hypothetical scenarios aren't «let's assume that everyone are bonkers and do crazy stuff», since well, if they are, we need to fix that. The problem then isn't that they're uploading packages which are not appropriate for the archive, it's that they don't understand why that is a problem. What is bonkers and what is not is very subjective, and that's the problem here. If I was a systemd maintainer I would consider it a reasonable option to rather upload a new version of systemd that adds such a dependency to udev instead of shipping an ancient systemd in the next release. Or would you want to ship systemd 204 in jessie if that would hypothetically be the only option for providing logind for non-systemd in the jessie timeframe? You can't regulate «don't be crazy», since if people want to, or don't understand what crazy means they will route around such a decision using technicalities. That's why in the case of Debian supporting multiple init systems (and optionally additionally non-Linux ports) there has to be a strict policy enforcing that this also stays supported. If you go bonkers tomorrow and add a dependency on systemd-sysv to udev, will that be considered an RC bug that will prevent your package from ever reaching testing until a udev without that dependency will be in the archive? [1] If multiple init systems should be supported accordinng to the CTTE decision, then the CTTE decision has to make it clear that Yes is the answer to that question. cu Adrian [1] Whether the dependency gets removed from udev or whether a second (forked) version of udev is needed depends on the technicalities. -- 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: Init system resolution open questions
On Sun, Jan 19, 2014 at 02:59:01AM -0800, Russ Allbery wrote: Adrian Bunk b...@stusta.de writes: On Sat, Jan 18, 2014 at 08:49:48PM -0800, Russ Allbery wrote: ... No, I am not assuming bad faith. But there will be cases where the goals like 1. give users of systemd under Linux the best possible experience 2. support non-Linux ports 3. support other init systems conflict. What is better depends on which goal has a higher priority for you. There shoud be a general project direction that clearly defines which of these two goals has a higher priority for Debian, not half of the packages going into one direction and the other half into the other direction. I don't even agree with this. I think it's perfectly reasonable for some Debian contributors to choose to put more of their time into giving users of the default init system on Linux the best possible experience, and other Debian contributors to concentrate on supporting non-Linux ports or other init systems, depending on what that individual maintainer feels is the most important and what they want to spend time on. The point of this bug is to choose a default init system. With most of those choices come obvious benefits if we add native support for that init system to our packaging. That doesn't mean anyone is obligated to do so. It does mean that they shouldn't stand in the way of other people doing so. Some packages are going to be converted to native support for the default init system quickly, some slowly, and different contributors will use different approaches. That's fine. Why do you want Debian to support multiple init systems in the first place? See also below. The following are two quite different options: 1. support multiple init systems since the non-Linux ports are core functionality of Debian 2. support multiple init systems, without considering the non-Linux ports to be core functionality of Debian that has to be protected One major reason for people supporting multiple init systems is to allow Debian to keep the non-Linux ports.[2] So they want 1., but might be very surprised if it turns out what they actually got with their vote was 2., and that the non-Linux ports might anyway die in jessie+1.[3] And this does matter also since supporting multiple init systems will be a lot more work than a one-time switch from sysvinit to a successor. I understand what you're saying, I think, and I believe it's the point of wording that Ian and I have been discussing: what are we requiring maintainers to do when patches are submitted for a non-default init system? I think I already said what my position on that is. People should not get in the way of other people's work if possible. And obviously for jessie people shouldn't drop sysvinit scripts. I don't know if we're going to be able to decide right now if people will be able to drop sysvinit scripts post-jessie. I think it may be better to wait and see what the landscape looks like then. I think this is a different question than dependencies on logind, because in that case we're dealing with upstream decisions to move strongly in a particular direction. That's much different than most of the issues we'll run into with multiple init systems, where the configuration for different init systems is largely independent. Hopefully, logind will continue to work without systemd and people will volunteer to maintain the necessary packaging for that configuration, and none of this will be a problem. I think you missed my point. Assume a CTTE member wants that Debian does continue to have non-Linux ports, and therefore wants Debian to make the extra efforts for supporting a second init system besides systemd. What level of support (if any) would that guarantee for Debian's ports to non-Linux kernels? Or more generally speaking: Supporting multiple init systems in the packages as well as all use cases like switching the init system of a running system will be a big effort from both init system maintainers and maintainers maintaining packages with init scripts. What are the goal(s) you want to achieve with forcing the big additional effort for supporting multiple init systems on Debian maintainers? And is that additional effort well-spent? Will these goal(s) be reached? 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: Init system resolution open questions
On 19/01/14 12:20, Adrian Bunk wrote: Why do you want Debian to support multiple init systems in the first place? I think because: * whichever is chosen as default, there will be some users who specifically don't like it, or specifically want something else (including major consumers like Ubuntu (Upstart), or Spotify (systemd), or Google (SysV)) * the non-Linux ports may have no choice but to get some other init system working anyway (if systemd is chosen as the default on Linux - I am quite certain it would never be ported) * if people are going to be doing the above work anyway, let's make it available to everyone, Linux and non-Linux users alike * if the chosen init system turns out to be a disaster, we'd have an easy way out if we weren't fully reliant on it; or maybe another init system comes along for jessie+1, better than anything we have now, we'd have more agility in being able to adopt it right away (not like this current situation) What level of support (if any) would that guarantee for Debian's ports to non-Linux kernels? I don't think anyone can guarantee that in a volunteer project; nobody can be forced to do the work if they don't want to. Porters may have to work hard and restore any lost functionality they care enough about. I imagine such problems will be RC-severity bugs, so it should be possible within existing practices to get patches applied or NMUd. 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: Init system resolution open questions
]] Adrian Bunk On Sun, Jan 19, 2014 at 11:00:01AM +0100, Tollef Fog Heen wrote: ]] Adrian Bunk I already gave my hypothetical udev gets a hard dependency on systemd as init system worst case. To make the worst case even worse, assume a new upstream version of systemd with this change gets released 2 weeks before the jessie freeze, and gets uploaded into unstable immediately.[1] Then the systemd maintainer (i.e. me and the rest of the team) should be bopped on the head. I'd appreciate if your hypothetical scenarios aren't «let's assume that everyone are bonkers and do crazy stuff», since well, if they are, we need to fix that. The problem then isn't that they're uploading packages which are not appropriate for the archive, it's that they don't understand why that is a problem. What is bonkers and what is not is very subjective, and that's the problem here. No, it's not subjective. If I was a systemd maintainer I would consider it a reasonable option to rather upload a new version of systemd that adds such a dependency to udev instead of shipping an ancient systemd in the next release. Or would you want to ship systemd 204 in jessie if that would hypothetically be the only option for providing logind for non-systemd in the jessie timeframe? That's not the point. The point is that it's not reasonable to break other people's packages in a significant and work-intensive manner two weeks before release, which is your scenario. There is no way that's ok. On the other hand, trying to formalise exactly how much you can inconvenience somebody how far in advance of the release is a futile exercise. Is requiring one other package to make a tiny change two years in advance of the freeze ok? If so, how about one year? One month? 20 days? etc. Don't regulate it explicitly but tell people that they have to behave reasonably towards their fellow developers. If people have no idea what that means, we already have a problem and need to fix that. If they disagree over the minutae, that's fine and we might need to decide exactly where the line goes in a few cases, but we can do that when the problem shows up, rather than try to antipacitate every case where it might go wrong. You can't regulate «don't be crazy», since if people want to, or don't understand what crazy means they will route around such a decision using technicalities. That's why in the case of Debian supporting multiple init systems (and optionally additionally non-Linux ports) there has to be a strict policy enforcing that this also stays supported. If you go bonkers tomorrow and add a dependency on systemd-sysv to udev, will that be considered an RC bug that will prevent your package from ever reaching testing until a udev without that dependency will be in the archive? [1] I sure hope so. If nothing else because the package is uninstallable without manual override. It'd break unrelated packages. It'd probably break d-i. If multiple init systems should be supported accordinng to the CTTE decision, then the CTTE decision has to make it clear that Yes is the answer to that question. Regulating the way you are advocating means you're moving the Overton window on what's considered acceptable or borderline acceptable and so I really don't think that's a good idea. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Init system resolution open questions
On Sun, Jan 19, 2014 at 04:05:08PM +0100, Tollef Fog Heen wrote: ]] Adrian Bunk ... If I was a systemd maintainer I would consider it a reasonable option to rather upload a new version of systemd that adds such a dependency to udev instead of shipping an ancient systemd in the next release. Or would you want to ship systemd 204 in jessie if that would hypothetically be the only option for providing logind for non-systemd in the jessie timeframe? That's not the point. The point is that it's not reasonable to break other people's packages in a significant and work-intensive manner two weeks before release, which is your scenario. There is no way that's ok. On the other hand, trying to formalise exactly how much you can inconvenience somebody how far in advance of the release is a futile exercise. Is requiring one other package to make a tiny change two years in advance of the freeze ok? If so, how about one year? One month? 20 days? etc. Don't regulate it explicitly but tell people that they have to behave reasonably towards their fellow developers. ... The problem is not a question of weeks or years. It is about setting the goals that should be achieved before discussing the way to reach them. Possible goals that require Debian to support multiple init systems include: - allow everyone who dislikes systemd to have the full functionality of Debian available with a different init system or - provide all/some major desktop environments with non-Linux ports or - allow non-Linux ports to be fully functional as server (but not necessarily as desktop) or - ... Let me make an example where that affects you: [0] When I asked regarding switching the init system of a running system, Ian Jackson answered: It seems obvious to me that if multiple ones are supported that there has to be some way to get from using one to using a different one. So if anything is not working regarding switching a running system from systemd to sysvinit for jessie,[1] then that will be a (likely RC) bug in your package [2] that you as systemd maintainers will have to fix. Making you spend your efforts on supporting switching the init system to and from systemd only makes sense when that results in actually reaching a goal that is considered worth the effort. Supporting multiple init systems alone is not sufficient for achieving any of the possible goals I've listed above, and the effort is only worth it when there is a clear understanding of the goal(s) and the complete requirements for achieving these goal(s). cu Adrian [0] assuming the decision is multiple init systems, including systemd [1] it would clearly involve a reboot, but calling the right reboot(8) can already be tricky [2] assuming the problem is not on the sysvinit side -- 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: Init system resolution open questions
I think you and I have some fundamental disagreements about how this decision-making process should work, so I'm not sure that we're going to reach some satisfactory conclusion to this discussion. But I'll take another try at this from another angle and see if it helps. Adrian Bunk b...@stusta.de writes: I think you missed my point. Assume a CTTE member wants that Debian does continue to have non-Linux ports, and therefore wants Debian to make the extra efforts for supporting a second init system besides systemd. What level of support (if any) would that guarantee for Debian's ports to non-Linux kernels? I largely agree with Tollef's response. I don't think that viewing this as a guarantee is a useful way of looking at the issue. Let me provide a concrete example. Right now, we have a kFreeBSD port that was, for wheezy, a technology preview, and for which we've generally applied a release architecture attitude towards bugs. However, I maintain a package that is simply not available on kFreeBSD (OpenAFS). It's not been ported, I personally don't have the knowledge to figure out how to turn the upstream FreeBSD kernel support into something that would work in Debian, and if no one else steps forward to do the work, it's very likely to continue to be unsupported. This hasn't caused anyone any angst or excitement, despite the fact that, in a concrete way, one of Debian's non-Linux ports is not as well-supported as its Linux ports. There's a piece of software (one that is quite important to some of our users) that is missing. And yet, the port is still useful to the people who care about it. Now, GNOME is obviously a much more significant and higher-profile piece of software, and there's also a difference between something that has never been supported and something that used to be supported but for which upstream has dropped support. But the situations are more similar than different, I think. See also the state of OpenJDK on kFreeBSD, which has been tentative for a while, but which again does not destroy the value of the port to the people who are using it. The short version is that the level of support will be whatever people have the time and inclination to achieve. Now, what I hear you saying is, roughly, that you don't think that level of support is worth the amount of work that would be required to maintain parallel init systems, switching between init systems, and so forth, and that either we should require a higher level of support than that, or we should drop the whole concept of supporting multiple init systems. You may be right that the level of effort is not worth it, which is one of the reasons why I'm hestitant to lay out a bunch of requirements in advance for Debian contributors to do a lot of work. However, I think we disagree about whether we should decide this tradeoff in advance. I also think you're overstating the amount of effort involved for the typical package. This is exactly why I didn't trust my intuition and actually went and did the work for one of my packages. I found that it really wasn't that much work to support multiple init systems, and it's work that mostly only has to be done once, and it's work that someone else can easily contribute and the maintainer can just incorporate. Yes, it's a lot of work for the init systems themselves, and for some packages with complex setup requirements, particularly to support switching, but that's also easier to test and to develop, because someone who cares about the problem can join that maintenance team and extensively test that one package. The work is isolated and easier to focus on. Or those packages can be dropped on the port, depending on how important they seem. Also, just to expand on my previous example with another package: I am upstream for a different package (lbcd, as it turns out, which I also used as a test package for this discussion) that didn't have support for some of its kernel operations on FreeBSD. It therefore failed to build on kFreeBSD, and life went on. However, the lack of builds on all of Debian's platforms bothered me at an aesthetic level, even though no one ever asked for the package on kFreeBSD and so far as I could tell no one cared. So, late last year, I took a few hours, did a bit of research, discovered that porting the package to kFreeBSD under a set of assumptions that are probably true of all Debian kFreeBSD systems wasn't actually hard, and ported it. It's unlikely that anyone is going to care, but it made me feel good to do it, and it wasn't that much effort. This is exactly the sort of thing that Debian makes possible, and is exactly the sort of thing that I don't want to *rule out* proactively in a decision. I think it would have been ridiculous to *force* me to port lbcd to kFreeBSD in some way (such as making it a requirement for lbcd to be in the archive). But if the facilities are available (I used the porter system to test, for instance), some people
Bug#727708: Init system resolution open questions
* Russ Allbery (r...@debian.org) [140118 05:15]: Steve Langasek vor...@debian.org writes: I don't believe we need to know the answer to these questions to know that Ian's requirement is a correct one. If we are saying that packages cannot drop their sysvinit scripts in jessie in order to ensure smooth upgrades, then the same requirement should apply to desktop environments, even if we don't know at the moment precisely how the maintainers of the affected packages will solve this - because having smooth upgrades between releases is a *baseline* for the quality of Debian integration, and we should not vacillate merely because some people fear it will be hard in this particular case. I believe it is reasonable to allow GNOME to require systemd as the init system if that's the only way to get a working logind with the software that we release with jessie, and I don't believe holding systemd to pre-206 in order to make that possible makes sense. 204 will be getting pretty long in the tooth by the time we get to the jessie release. I however believe that it would be a major fault if installation of gnome would exchange the init system / pid1, so my expectation on Debian would be that we integrate into a system where Gnome could be used without systemd as pid1 or systemwide init-system (having gnome require systemd to be installed as a daemon however would be ok, same as e.g. cereal depends on runit - nothing new, and nothing worrying). In other words, it's not that I want to say the *opposite* of what Ian stated as consensus. Rather, I want to make sure that we don't rule on things that we don't need to be ruling on, and make sure that we don't write a decision that effectively ends up telling the GNOME team that they have to get the version they target for jessie working without logind or have it removed from the archive. working without systemd doesn't translate for me into they are not allowed to use new features of systemd, so it might be that gnomes integration with systemd is better than with other init-systems / pid1 providers. But I would consider it inappropriate if apt-get install gnome replaces my initsystem / pid1. Separately, I don't agree that it's actually hard to support logind on non-systemd for jessie. This already works for v204, and the work to support v205 is in progress. In this case, omitting this requirement from our ruling won't actually make any difference, since it will be easy to support and hence uncontroversial. So, either way, I think we should make sure the statement we make permits packages to depend on logind. Perhaps we could add an comment saying that as the situation is as of above, we don't expect an issue programms requiring logind. Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Init system resolution open questions
On Fri, Jan 17, 2014 at 08:13:30PM -0800, Russ Allbery wrote: ... I believe it is reasonable to allow GNOME to require systemd as the init system if that's the only way to get a working logind with the software that we release with jessie, Why does logind actually have to be a hard dependency for GNOME in jessie? May someone correct me if I'm wrong, but as far as I can see from a quick look at the sources, as of today GNOME still supports ConsoleKit as alternative to logind. And if the Debian GNOME maintainers would tell GNOME upstream that shipping GNOME 3.14 in jessie would only be possible if the existing ConsoleKit support does not get removed until then, that might be enough for having that working in jessie. and I don't believe holding systemd to pre-206 in order to make that possible makes sense. 204 will be getting pretty long in the tooth by the time we get to the jessie release. ... What is your general position on what dependencies on a specific init system are acceptable, and which are not, if the CTTE decision will be that Debian will support multiple init systems? Worst case: I can imagine valid technical reasons why systemd upstream might make udev depend on other parts of systemd. Hypothetically, tomorrow a new systemd release might be released where udev depends on systemd being the init system. network-manager is among the packages that already switched from ConsoleKit to logind in experimental (upstream still supports both). Looking at popcon stats, network-manager is used by 40% of all Debian users. udev is used by 99% of all users of Debian on Linux. [1] What percentage of Debian users locked into one init system by package dependencies would be the threshold for making a CTTE decision Debian supports multiple init systems a farce? cu Adrian [1] using the Inst stats from popcon, since the Vote number looks bogus and it is unlikely that many people have udev installed without using it -- 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: Init system resolution open questions
On Fri, Jan 17, 2014 at 11:29 AM, Thorsten Glaser wrote: Moritz Muehlenhoff dixit: FreeBSD upstream isn't a desktop OS and never will be, there're just too many deficiencies (e.g. lack of dbus Eh, excuse me! It’s obviously possible to run a desktop without dbus! In fact, this is a feature, in my eyes. I think Moritz's point is that the project should get to the point where it is perceived as ok for the non-linux ports to lose things like gnome once it entirely depends on linux-only features (lots of alternative desktops xfce, lxde, etc. still of course remain). To make that ok, the % build requirement for kfreebsd/hurd will probably need to be reduced. 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: Init system resolution open questions
Adrian Bunk b...@stusta.de writes: Why does logind actually have to be a hard dependency for GNOME in jessie? If it doesn't, then it's not an issue. But it seemed like at least a possibility given upstream GNOME direction. What is your general position on what dependencies on a specific init system are acceptable, and which are not, if the CTTE decision will be that Debian will support multiple init systems? In general, I think it should be up to the maintainers of that package, with the understanding that it's potentially pretty obnoxious for our users to require one init system, so it's not something to do lightly. I truly don't think this will be a problem. Debian contributors already understand this sort of thing. If software that people want to package for Debian is deeply entangled in one init system (that is supported in Debian), for good or for ill, regardless of what one might think of the decisions made by upstream that created that situation, I think it's going rather far to require the Debian package maintainers to port it to different init systems in order to get (or keep) their package in Debian. I have a very hard time defending that position. Worst case: I can imagine valid technical reasons why systemd upstream might make udev depend on other parts of systemd. Hypothetically, tomorrow a new systemd release might be released where udev depends on systemd being the init system. network-manager is among the packages that already switched from ConsoleKit to logind in experimental (upstream still supports both). Looking at popcon stats, network-manager is used by 40% of all Debian users. Note that I expect popcon stats to massively overcount desktops relative to servers, so I'm pretty sure this percentage is wildly inflated. For example, I have more than 200 systems not reporting to popcon (it's hard to justify running popcon from a security perspective since, although the risk is low, the upside for my employer is also very low), and not a single one of them runs network-manager. They all just use ifupdown. I expect that to be a very common scenario. udev is used by 99% of all users of Debian on Linux. [1] udev is getting close to required on Linux already. I'm not sure how many people are testing the non-udev code paths, particularly for more obscure packages. And that's the way I would expect this to go. The non-default cases that are rarely used will tend to bitrot unless someone who cares about them puts the work into making sure they keep working, and there's some way to do that work that doesn't put too much of a burden on everyone else. What percentage of Debian users locked into one init system by package dependencies would be the threshold for making a CTTE decision Debian supports multiple init systems a farce? I don't think percentage of users is the right metric. By that metric, Debian doesn't support kFreeBSD or Hurd right now. And yet, we do, even though some of our software is not ported to those platforms yet (and possibly ever). I'm not sure the exact answer to your question, but I don't believe that GNOME requiring systemd would make Debian supports multiple init systems a farce. There are a bunch of other desktop environments, some of which have more interest in portability (including to non-Linux, which would obviously rule out a hard systemd dependency), as well as a bunch of ways to use Debian that don't involve a desktop environment at all (like servers). It would be nice if we could avoid it as long as people have reasons to not want to use systemd (which may be indefinitely), but I also don't think that burden should be carried by the GNOME package maintainers. *If* it ends up being a burden. Steve doesn't think it will be much of a burden, and I hope he's right. -- 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: Init system resolution open questions
On Sat, Jan 18, 2014 at 09:45:35AM -0800, Russ Allbery wrote: ... If software that people want to package for Debian is deeply entangled in one init system (that is supported in Debian), for good or for ill, regardless of what one might think of the decisions made by upstream that created that situation, I think it's going rather far to require the Debian package maintainers to port it to different init systems in order to get (or keep) their package in Debian. I have a very hard time defending that position. So in the hypothetical case that systemd upstream decides to make udev hard depend on systemd being pid 1, would you even defend that such a change could go into jessie if the CTTE decision was that Debian should support multiple init systems? Worst case: I can imagine valid technical reasons why systemd upstream might make udev depend on other parts of systemd. Hypothetically, tomorrow a new systemd release might be released where udev depends on systemd being the init system. ... udev is used by 99% of all users of Debian on Linux. [1] udev is getting close to required on Linux already. ... We are in full agreement on that. And my point on top of that is that if the CTTE decsion would be that Debian should support multiple init systems, but it does not set a policy limiting strictly what hard dependencies on systemd are allowed, then it would be better if the CTTE would rule that Debian should support only systemd since that's what would anyway happen in practice through package dependencies pretty soon. If Debian wants to support multiple init systems and wants to continue supporting non-Linux ports, then Debian's policy must force Debian maintainers to put pressure on their upstreams to keep support for non-systemd systems and for non-Linux kernels. And where that is not possible, such issues have to be resolved before the packages hit unstable. [1] cu Adrian [1] E.g. in the hypothetical udev worst case, a second udev package based on a fork that does not depend on systemd might be required. -- 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: Init system resolution open questions
Adrian Bunk b...@stusta.de writes: On Sat, Jan 18, 2014 at 09:45:35AM -0800, Russ Allbery wrote: If software that people want to package for Debian is deeply entangled in one init system (that is supported in Debian), for good or for ill, regardless of what one might think of the decisions made by upstream that created that situation, I think it's going rather far to require the Debian package maintainers to port it to different init systems in order to get (or keep) their package in Debian. I have a very hard time defending that position. So in the hypothetical case that systemd upstream decides to make udev hard depend on systemd being pid 1, would you even defend that such a change could go into jessie if the CTTE decision was that Debian should support multiple init systems? It would, of course, depend on *why* they made that decision, but at least on the surface that seems like it would prevent us from either supporting multiple init systems or having a reasonable upgrade from sysvinit. Those would both be significant drawbacks, so I think in such a situation we should look for alternatives. (And I know the udev maintainer really wants to require a modern init system -- that was one of the messages that set off this discussion -- but I do think it would be worthwhile waiting until after jessie to take that step.) You may be noticing a theme here: I'm refusing to take hard positions, in advance, on theoretical future possibilities. I think that's part of the responsibility of the Technical Committee. See 6.3.6: Technical Committee makes decisions only as last resort. The Technical Committee does not make a technical decision until efforts to resolve it via consensus have been tried and failed, unless it has been asked to make a decision by the person or body who would normally be responsible for it. I believe the spirit of that provision includes not borrowing trouble for ourselves by making definitive statements about future events that may or may not happen. Remember, the context of this discussion is around whether the Technical Committee, assuming that we choose systemd as a default, will require that all software in Debian that's part of the jessie release work with sysvinit as well. I'm pointing out edge cases and possible drawbacks to making a firm and sweeping statement without knowing, in advance, *why* some piece of software doesn't work with sysvinit. Other people have pointed out other cases, such as software that was never part of previous releases and hence doesn't pose upgrade issues. We are in full agreement on that. And my point on top of that is that if the CTTE decsion would be that Debian should support multiple init systems, but it does not set a policy limiting strictly what hard dependencies on systemd are allowed, then it would be better if the CTTE would rule that Debian should support only systemd since that's what would anyway happen in practice through package dependencies pretty soon. And yet there are still people who use Debian without udev (or at least I think there is based on debian-devel discussion). Why go out of our way to tell those people to go away? There is a natural process here, where rarely-used configurations slowly stop working and people eventually decide not to bother to keep them working and move on to other things. Eventually, they may acquire RC bugs that no one wants to fix and be dropped, or the package maintenance team may decide that they just can't support the configuration any more, make a public call for people to step forward and maintain it, and, when that call isn't answered, drop support. The drawback of trying to short-circuit that process is that it's quite easy to guess wrong and decide to proactively drop support for something that turns out to not be that hard to continue to support, or that someone else wants to support and is willing to do all the work to support. I'd rather leave it to the expert analysis of the people directly involved, and don't want to skip past the courtesy of inviting people to find a way to fix the problem if they care about it. To take another example, do you think the Technical Committee should have said that file-rc is not supported? I don't see why we should make that sort of proactive statement. Yes, it doesn't work very well, and has some problems, but people have still been using it, and people are still willing to fix problems with it, so why go out of our way to tell those people to stop? In other words, I would rather be clear about what we consider to be the primary technical direction, and the core functionality that we should try to support, and let the long tail and personal projects take care of themselves. Some of them will fade away, some of them will putter along in the background without hurting anyone, and we may be quite surprised by one of them becoming a huge asset to the project later on. That's why I like the framing
Bug#727708: Init system resolution open questions
On Fri, Jan 17, 2014 at 12:51:48PM +, Ian Jackson wrote: Adrian Bunk writes (Re: Bug#727708: Init system resolution open questions): (Only as a PM since I am repeating myself.) Thanks for your mail. I think it deserves wider consideration. One question you should consider adding: * What switching between init systems has to be supported? Should it be possible for the user to switch from one supported init system to another supported init system at any point (it is OK if that requires a reboot), or is it acceptable if that is not possible in all cases or even not at all? It seems obvious to me that if multiple ones are supported that there has to be some way to get from using one to using a different one. So the question is more one of how difficult it is. If it is clear for you that this is a requirement, please state it explicitely for the multiple init systems supported option: * Any supported init system must support switching a running system from any other supported init system to this init system, as well as switching a running system from this init system to any other supported init system. This switch is expected to require a reboot. Thanks, Ian. 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: Init system resolution open questions
On Sat, Jan 18, 2014 at 11:22:06AM -0800, Russ Allbery wrote: Adrian Bunk b...@stusta.de writes: ... We are in full agreement on that. And my point on top of that is that if the CTTE decsion would be that Debian should support multiple init systems, but it does not set a policy limiting strictly what hard dependencies on systemd are allowed, then it would be better if the CTTE would rule that Debian should support only systemd since that's what would anyway happen in practice through package dependencies pretty soon. And yet there are still people who use Debian without udev (or at least I think there is based on debian-devel discussion). Why go out of our way to tell those people to go away? Considering that even the X server package depends on udev, there are only some niches where it is still possible at all to use Debian on Linux without udev - and it is slowly evolving into becoming impossible. There is a natural process here, where rarely-used configurations slowly stop working and people eventually decide not to bother to keep them working and move on to other things. Eventually, they may acquire RC bugs that no one wants to fix and be dropped, or the package maintenance team may decide that they just can't support the configuration any more, make a public call for people to step forward and maintain it, and, when that call isn't answered, drop support. ... The problem is different - with systemd there is a fast process going on where frequently-used configurations stop working without systemd. And the problem is exactly that without a strong policy there will not be RC bugs anywhere - when it is fine for everyone to depend on systemd, then any bugs demanding support for other init systems can just be tagged wontfix by the Debian maintainer of the package. In other words, I would rather be clear about what we consider to be the primary technical direction, and the core functionality that we should try to support, and let the long tail and personal projects take care of themselves. Some of them will fade away, some of them will putter along in the background without hurting anyone, and we may be quite surprised by one of them becoming a huge asset to the project later on. That's why I like the framing of this discussion as deciding the *default*. Are in your opinion Debian's non-Linux ports part of the core functionality that we should try to support? And if yes, with the whole set of Debian's functionality or only with some specific subset (e.g. only for headless servers)? AFAIR even the make logind usable without systemd discussions don't mention that this won't make logind available for Debian's non-Linux ports. 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: Init system resolution open questions
Adrian Bunk b...@stusta.de writes: On Sat, Jan 18, 2014 at 11:22:06AM -0800, Russ Allbery wrote: There is a natural process here, where rarely-used configurations slowly stop working and people eventually decide not to bother to keep them working and move on to other things. Eventually, they may acquire RC bugs that no one wants to fix and be dropped, or the package maintenance team may decide that they just can't support the configuration any more, make a public call for people to step forward and maintain it, and, when that call isn't answered, drop support. The problem is different - with systemd there is a fast process going on where frequently-used configurations stop working without systemd. Are you only thinking of logind with desktop environments here, or are you thinking of something else? I don't think this process is actually very fast (we've been arguing about this for at least a year), and I think you're overstating this case, but maybe I missed something. If you're just referring to GNOME, one desktop environment currently switched over doesn't strike me as very fast, and whether that's the path forward for that desktop environment for jessie is to a large extent what we're debating here. I think it's also important here to distinguish between decisions that Debian maintainers make and decisions *upstream* makes that Debian maintainers choose not to *reverse*. Those are two very, very different situations, and I think they're being treated interchangeably way too much in these discussions. We ask Debian maintainers to integrate their packages with the distribution, but we don't, in general, ask them to maintain long-term major forks in order to do so. When we run into a situation where that looks like it might be necessary, we generally start a conversation about it and try to make a decision about the best path forward based on the specifics of that individual case. And the problem is exactly that without a strong policy there will not be RC bugs anywhere - when it is fine for everyone to depend on systemd, then any bugs demanding support for other init systems can just be tagged wontfix by the Debian maintainer of the package. This sounds like you're assuming a level of bad faith that I really don't think is appropriate. I don't want to give Debian maintainers orders in advance just because we're worried they might otherwise do the wrong thing. I think it's more likely that they'll make *better* decisions for their own packages when people aren't telling them specifically what to do, just advising on general project direction. Are in your opinion Debian's non-Linux ports part of the core functionality that we should try to support? No, which is not the same thing as saying that they're not supported. (More than 80% of the packages I maintain are similarly not part of the core functionality we should try to support.) AFAIR even the make logind usable without systemd discussions don't mention that this won't make logind available for Debian's non-Linux ports. That's been discussed at length in the bug to which you are responding. I realize it's quite long and has quite a lot of messages, though, so it's easy to lose track of what's been talked about. -- 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: Init system resolution open questions
On Sat, Jan 18, 2014 at 08:49:48PM -0800, Russ Allbery wrote: Adrian Bunk b...@stusta.de writes: On Sat, Jan 18, 2014 at 11:22:06AM -0800, Russ Allbery wrote: There is a natural process here, where rarely-used configurations slowly stop working and people eventually decide not to bother to keep them working and move on to other things. Eventually, they may acquire RC bugs that no one wants to fix and be dropped, or the package maintenance team may decide that they just can't support the configuration any more, make a public call for people to step forward and maintain it, and, when that call isn't answered, drop support. The problem is different - with systemd there is a fast process going on where frequently-used configurations stop working without systemd. Are you only thinking of logind with desktop environments here, or are you thinking of something else? I don't think this process is actually very fast (we've been arguing about this for at least a year), and I think you're overstating this case, but maybe I missed something. If you're just referring to GNOME, one desktop environment currently switched over doesn't strike me as very fast, and whether that's the path forward for that desktop environment for jessie is to a large extent what we're debating here. I am not only talking about GNOME, or only about logind. I already gave my hypothetical udev gets a hard dependency on systemd as init system worst case. To make the worst case even worse, assume a new upstream version of systemd with this change gets released 2 weeks before the jessie freeze, and gets uploaded into unstable immediately.[1] In this hypothetical even worse worst case, would you consider such an immediate upload to unstable a valid action of the Debian systemd maintainers, or would you word the CTTE decision in a way that would make it clear that an action like this would not be appropriate? Note that this is a hypothetical (but not completely impossible) example and I am not implying that the Debian systemd maintainers would actually do such an upload in such a situation My point is that the CTTE decision has to cover such cases, to avoid in this hypothetical even worse worst case huge flamewars and possibly even a GR during the freeze delaying the release of jessie. IMHO the whole point of having a CTTE decision on the init system question is to have the issue settled in a way that any major disagreements can be resolved by referring to the text of the CTTE decision. I think it's also important here to distinguish between decisions that Debian maintainers make and decisions *upstream* makes that Debian maintainers choose not to *reverse*. Those are two very, very different situations, and I think they're being treated interchangeably way too much in these discussions. We ask Debian maintainers to integrate their packages with the distribution, but we don't, in general, ask them to maintain long-term major forks in order to do so. ... The best way to avoid long-term major forks is when the Debian maintainers make it clear to upstream that e.g. ConsoleKit codepaths shouldn't be dropped upstream since that would make it harder for Debian's non-Linux ports. And in the cases where it doesn't work, it is very likely that supporting any non-systemd init system will imply that Debian will have to maintain or at least adopt long-term major forks. logind is one example for such a long-term major fork. And the problem is exactly that without a strong policy there will not be RC bugs anywhere - when it is fine for everyone to depend on systemd, then any bugs demanding support for other init systems can just be tagged wontfix by the Debian maintainer of the package. This sounds like you're assuming a level of bad faith that I really don't think is appropriate. I don't want to give Debian maintainers orders in advance just because we're worried they might otherwise do the wrong thing. I think it's more likely that they'll make *better* decisions for their own packages when people aren't telling them specifically what to do, just advising on general project direction. No, I am not assuming bad faith. But there will be cases where the goals like 1. give users of systemd under Linux the best possible experience 2. support non-Linux ports 3. support other init systems conflict. What is better depends on which goal has a higher priority for you. There shoud be a general project direction that clearly defines which of these two goals has a higher priority for Debian, not half of the packages going into one direction and the other half into the other direction. To make an example: In my hypothetical udev gets a hard dependency on systemd as init system worst case, the best decision for the Debian systemd maintainers for their own packages might be to deliver the latest systemd to their users immediately. For anyone using another init system, this will
Bug#727708: Init system resolution open questions
Tollef Fog Heen writes (Bug#727708: Init system resolution open questions): [Ian Jackson]: As I mentioned on IRC, I think we need to get some clear answers to certain questions from everybody. It's not clear to me that the CTTE is allowed to rule on a bunch of those questions, especially the RC bug ones seem to directly contradict both 6.3.5 and 6.3.6 in the constitution. The release team is the team that sets RC policies and I'm not aware of any failed attempts at arriving at a consensus with them or that they've delegated the decision to the CTTE. Under the circumstances I think it would be appropriate for the committee to give appropriate advice. 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: Init system resolution open questions
Adrian Bunk writes (Re: Bug#727708: Init system resolution open questions): (Only as a PM since I am repeating myself.) Thanks for your mail. I think it deserves wider consideration. One question you should consider adding: * What switching between init systems has to be supported? Should it be possible for the user to switch from one supported init system to another supported init system at any point (it is OK if that requires a reboot), or is it acceptable if that is not possible in all cases or even not at all? It seems obvious to me that if multiple ones are supported that there has to be some way to get from using one to using a different one. So the question is more one of how difficult it is. 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: Init system resolution open questions
]] Ian Jackson Tollef Fog Heen writes (Bug#727708: Init system resolution open questions): [Ian Jackson]: As I mentioned on IRC, I think we need to get some clear answers to certain questions from everybody. It's not clear to me that the CTTE is allowed to rule on a bunch of those questions, especially the RC bug ones seem to directly contradict both 6.3.5 and 6.3.6 in the constitution. The release team is the team that sets RC policies and I'm not aware of any failed attempts at arriving at a consensus with them or that they've delegated the decision to the CTTE. Under the circumstances I think it would be appropriate for the committee to give appropriate advice. You're of course free to give advice. My point was that it's not binding (you can't rule on it). -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Init system resolution open questions
On Thu, Jan 16, 2014 at 01:01:51PM -0800, Russ Allbery wrote: I think that major packages that would be considered release blockers, which probably includes GNOME, KDE, and Xfce, need to support the default Linux init system in the sense that, if they don't, I don't think we can release. I think a substantial degredation of functionality when running on an init system other than the Linux default would be okay for for jessie+1. For jessie, I think it depends greatly on how feasible making them work with sysvinit is (and I suspect sysvinit support would be sufficient for all other purposes). I think we should move away from them target that the non-Linux ports should build the entire archive. FreeBSD upstream isn't a desktop OS and never will be, there're just too many deficiencies (e.g. lack of dbus, limited hardware support, only OSS sound drivers, limited KMS/3D support in Xorg etc. pp). So why should the Debian port with it's minimal porters achieve what upstream doesn't deliver? And for Hurd it's even more obvious. All the use cases mentioned for Debian kfreebsd are server-based (e.g. pf or NAS using ZFS). Why not focus on a useful subsection of Debian and get that right instead of fighting an uphill battle? Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Init system resolution open questions
Moritz Muehlenhoff dixit: FreeBSD upstream isn't a desktop OS and never will be, there're just too many deficiencies (e.g. lack of dbus Eh, excuse me! It’s obviously possible to run a desktop without dbus! In fact, this is a feature, in my eyes. limited hardware support Oh c’mon. Linux does not support any and all hardware either. only OSS sound drivers I fail to see where the problem is with this. limited KMS/3D support in Xorg As if that were not the case in Linux. Its support may be a bit broader but still limited. Sorry, but this is FUD. bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Init system resolution open questions
On Thu, Jan 16, 2014 at 12:08:41PM -0800, Russ Allbery wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: AFAICT we are all agreed that: * Applications which aren't part of the init system must not require a particular init to be pid 1. (So in particular a desktop environment may not require a particular pid 1.) I still have concerns about this. This position seems to be predicated on the assumption that applications will be able to depend on a working logind for jessie, and that a working logind will be provided for systems using sysvinit. This apparently works today with systemd-shim but will stop working with post-205 systemd. I want to understand whether setting this requirement means that we're intending to require that jessie ship with systemd 204, or, if not, what level of certainty we have that post-205 logind will work with sysvinit for jessie. I don't believe we need to know the answer to these questions to know that Ian's requirement is a correct one. If we are saying that packages cannot drop their sysvinit scripts in jessie in order to ensure smooth upgrades, then the same requirement should apply to desktop environments, even if we don't know at the moment precisely how the maintainers of the affected packages will solve this - because having smooth upgrades between releases is a *baseline* for the quality of Debian integration, and we should not vacillate merely because some people fear it will be hard in this particular case. The consequences of a desktop environment having a hard dependency on a particular init system in jessie are that a desktop system becomes unusable partway through the upgrade. If a user tries to open a new login session while the upgrade is in progress, or if for whatever reason the user running the upgrade logs out (or gets logged out due to a bug) and tries to log back in, this will in all likelihood fail. I don't think that's an acceptable outcome; so the requirement not to hard-depend on systemd follows directly from this. There may be other failure modes if the system is rebooted partway through the upgrade, but that's always the case, and doesn't speak against declaring a dependency on an init system. Separately, I don't agree that it's actually hard to support logind on non-systemd for jessie. This already works for v204, and the work to support v205 is in progress. -- 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: Init system resolution open questions
Steve Langasek vor...@debian.org writes: I don't believe we need to know the answer to these questions to know that Ian's requirement is a correct one. If we are saying that packages cannot drop their sysvinit scripts in jessie in order to ensure smooth upgrades, then the same requirement should apply to desktop environments, even if we don't know at the moment precisely how the maintainers of the affected packages will solve this - because having smooth upgrades between releases is a *baseline* for the quality of Debian integration, and we should not vacillate merely because some people fear it will be hard in this particular case. I believe it is reasonable to allow GNOME to require systemd as the init system if that's the only way to get a working logind with the software that we release with jessie, and I don't believe holding systemd to pre-206 in order to make that possible makes sense. 204 will be getting pretty long in the tooth by the time we get to the jessie release. So, basically, I disagree with this. Now, obviously, hopefully logind will work fine in the jessie release without requiring systemd as the init system, and this will all be theoretical, but I'm worried that we're going to paint ourselves into an unreasonable corner by stating a hard and fast rule about this before we know what the shape of the software will be at the time of the release. The consequences of a desktop environment having a hard dependency on a particular init system in jessie are that a desktop system becomes unusable partway through the upgrade. If a user tries to open a new login session while the upgrade is in progress, or if for whatever reason the user running the upgrade logs out (or gets logged out due to a bug) and tries to log back in, this will in all likelihood fail. I don't think that's an acceptable outcome; so the requirement not to hard-depend on systemd follows directly from this. Clearly the release team and the GNOME team will need to look at proper behavior during the upgrade, including aborted upgrades, but I think this is a separate issue that they would be looking at regardless. If the dependency causes separate RC issues around upgrades, obviously those issues will need to be addressed, but I'm dubious about simply *assuming* it will without looking at how the actual system could be assembled or letting people try to find good solutions to the problem. In other words, it's not that I want to say the *opposite* of what Ian stated as consensus. Rather, I want to make sure that we don't rule on things that we don't need to be ruling on, and make sure that we don't write a decision that effectively ends up telling the GNOME team that they have to get the version they target for jessie working without logind or have it removed from the archive. Separately, I don't agree that it's actually hard to support logind on non-systemd for jessie. This already works for v204, and the work to support v205 is in progress. In this case, omitting this requirement from our ruling won't actually make any difference, since it will be easy to support and hence uncontroversial. So, either way, I think we should make sure the statement we make permits packages to depend on logind. -- 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: Init system resolution open questions
I think what we need to decide at the meeting later today is: * Are we ready to make a decision ? * If anyone is not, what other information/research/etc. is required and how long will that take ? * If we are ready, what resolution texts should we be voting on ? * If we are ready, can we set a timetable for the vote itself to make sure that we hold the voting period during a time when everyone is going to be available ? (Constitutionally we can't extend the voting period, and it is IMO important that as many TC members as possible cast votes.) I'm hoping that the answer to the first question is yes. I'm happy to draft all the versions for everyone, although obviously every TC member is entitled to propose a resolution of their own. There are a number of questions on which TC members have so far expressed diverging views, or at least the answers aren't clear: Q1 (Obviously) What should be the default in jessie ? Q2 Should we declare an intent to support multiple systems for the foreseeable future ? Q3 Should we issue guidance on what kind of changes ought to be accepted by maintainers ? In particular, should we explicitly lay out certain objections as _not_ good reasons for a maintainer to accept an init system patch and what should be on that list of non-objections ? Q4 Do we want to retain some comment along the lines of my current draft's s11 Replacement of existing functionality. The combinatorial matrix of all these options, even after we drop any that don't have significant support, is going to be too unweildy. We mustn't vote on each question independently because people's views might intertwine the issues. My initial suggestion would be: Firstly, Q4 could be separated out as genuinely independent. If there is support for such a statement, it can come as a separate resolution. Regarding Q1-3 and other objections that arise from my drafts: constitutionally we put anything on the ballot that any TC member proposes. I suggest that TC members should request for combinations to be on the ballot if either (a) that combination is anyone's preferred outcome or (b) it makes a plausible compromise between some other pair of proposed options. Does that make sense ? Ian. PS: After I've found out what versions people care about, I'm tempted to turn my draft into something that can be automatically converted into various versions... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Init system resolution open questions
It turns out that we aren't quite ready. Don and Andreas say they will reply with their views by the end of the weekend. In particular we aren't settled on the support/enforcement/ requirement/status of the various sytems on the various platforms. AFAICT we are all agreed that: * sysv support needs to remain mandatory (RC-buggy if missing) in jessie. * Applications which aren't part of the init system must not require a particular init to be pid 1. (So in particular a desktop environment may not require a particular pid 1.) As I mentioned on IRC, I think we need to get some clear answers to certain questions from everybody. * For which init systems should there be a low nmu threshold for native support in packages ? * Daemon package maintainers should accept reasonable patches for some set of init systems. Which init systems ? * What opinions do we state for jessie+1 - are we hoping for one or two systems (which two), or more, or are we not saying yet ? * If systemd is the default on Linux, what opinions do we want to state, if any, re non-Linux ports at this stage ? * What should be an RC bug in jessie ? * What should be an RC bug in jessie+1 ? I also think we need to answer: * What level of dysfunction is OK if an application (or a desktop environment or whatever) isn't running on its preferred pid 1 ? * Do we want to give any guidance about what a maintainer may consider an unreasonable native-init-system-support patch ? Or to put it another way, do we intend to overrule a maintainer who declines to implement one (or any) non-forking startup protocol ? Please reply by the end of the weekend. It would be helpful if everyone would reply again even if the answers ought to be obvious from what you've said before. I will try to transfer the results into draft(s) in git. 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: Init system resolution open questions
Ian Jackson writes (Re: Bug#727708: Init system resolution open questions): As I mentioned on IRC, I think we need to get some clear answers to certain questions from everybody. My answers: * For which init systems should there be a low nmu threshold for native support in packages ? At least systemd, upstart and openrc, provided the policy guidance is in place. * Daemon package maintainers should accept reasonable patches for some set of init systems. Which init systems ? All. * What opinions do we state for jessie+1 - are we hoping for one or two systems (which two), or more, or are we not saying yet ? We would like to make provision of sysvinit scripts optional. We would like to continue to support multiple systems into the future so long as their communities remain healthy. Ideally there would be some kind of metalanguage or conversion or compatibility scheme that would allow at least simple cases to be dealt with without duplicated effort. * If systemd is the default on Linux, what opinions do we want to state, if any, re non-Linux ports at this stage ? We should express the hope that they will use upstart and that it will be suitably ready on both kFreeBSD and Hurd. * What should be an RC bug in jessie ? Lack of support for sysvinit. Dependency on a particular init system as pid 1. * What should be an RC bug in jessie+1 ? Lack of support for whatever the default is on Linux; also, lack of support for whatever the default is on kFreeBSD. Hopefully the Hurd default will be the same as kFreeBSD. In both cases support via sysvinit compatibility is acceptable to avoid the RC bug (but obviously support only via sysvinit compatibility is not desirable). I also think we need to answer: * What level of dysfunction is OK if an application (or a desktop environment or whatever) isn't running on its preferred pid 1 ? Interfaces or functions which access features of a particular init system are allowed to break. Basic functionality must still work. * Do we want to give any guidance about what a maintainer may consider an unreasonable native-init-system-support patch ? Or to put it another way, do we intend to overrule a maintainer who declines to implement one (or any) non-forking startup protocol ? A maintainer must not reject a patch solely because they don't care to support that init system. A maintainer _may_ reject a patch because they don't like the specific non-forking startup protocol being used. 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: Init system resolution open questions
On Thu, 2014-01-16 at 19:12 +, Ian Jackson wrote: AFAICT we are all agreed that: * Applications which aren't part of the init system must not require a particular init to be pid 1. (So in particular a desktop environment may not require a particular pid 1.) I read the log, and I don't see common agreement with that, at least not agreement with not allowing it as an effective requirement (as in GNOME can require interfaces which are only available with systemd as PID 1, though this might be expressed in ways other than a direct what is PID 1 dependency and it would at least in theory be possible that something else would provide the interfaces sometime in the future). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Init system resolution open questions
Ian Jackson ijack...@chiark.greenend.org.uk writes: AFAICT we are all agreed that: * Applications which aren't part of the init system must not require a particular init to be pid 1. (So in particular a desktop environment may not require a particular pid 1.) I still have concerns about this. This position seems to be predicated on the assumption that applications will be able to depend on a working logind for jessie, and that a working logind will be provided for systems using sysvinit. This apparently works today with systemd-shim but will stop working with post-205 systemd. I want to understand whether setting this requirement means that we're intending to require that jessie ship with systemd 204, or, if not, what level of certainty we have that post-205 logind will work with sysvinit for jessie. -- 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: Init system resolution open questions
]] Ian Jackson As I mentioned on IRC, I think we need to get some clear answers to certain questions from everybody. It's not clear to me that the CTTE is allowed to rule on a bunch of those questions, especially the RC bug ones seem to directly contradict both 6.3.5 and 6.3.6 in the constitution. The release team is the team that sets RC policies and I'm not aware of any failed attempts at arriving at a consensus with them or that they've delegated the decision to the CTTE. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Init system resolution open questions
Hi, Ian Jackson ijack...@chiark.greenend.org.uk writes: AFAICT we are all agreed that: [...] * Applications which aren't part of the init system must not require a particular init to be pid 1. (So in particular a desktop environment may not require a particular pid 1.) What about applications that are specifically designed to work with a particular init system? DSA was investigating setting up systemd for codesearch.debian.net which uses it to manage worker pools (including startup via socket activation and load balancing IIRC). Another example would be a seperate gnome-session-systemd package[1]. I don't think tech-ctte should forbid people to maintain such packages if they wish to. [1] Let's assume this only provides a (possibly non-default) alternative for and doesn't replace gnome-session here. Of course these might work (partially) if someone implemented enough of the systemd dbus interfaces to make the user systemd work without systemd being pid-1 as well. However (without having investigated this) I would assume this unlikely to happen. Maintainers only should not drop support for a (default) init system when the application supports it. This would be similar to the situation with different kernels: when applications support all of them, fine, but there may be programs that require a specific kernel. 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: Init system resolution open questions
Ian Jackson ijack...@chiark.greenend.org.uk writes: As I mentioned on IRC, I think we need to get some clear answers to certain questions from everybody. * For which init systems should there be a low nmu threshold for native support in packages ? I believe this should be the Linux default plus (if different) whatever init system is used by the non-Linux ports. (Putting aside the question of whether the Technical Committee can set an NMU threshold for the moment.) * Daemon package maintainers should accept reasonable patches for some set of init systems. Which init systems ? The same as the list for a low NMU threshold above. * What opinions do we state for jessie+1 - are we hoping for one or two systems (which two), or more, or are we not saying yet ? I think we should say that native (not via legacy sysvinit shell scripts) support for the Linux default is encouraged for jessie+1, and beyond that leave this alone. My fallback position would be to say that we expect to converge on at most two well-supported init systems, one for Linux ports and one for non-Linux ports. I think the question of whether to use OpenRC or upstart for non-Linux ports is best deferred. * If systemd is the default on Linux, what opinions do we want to state, if any, re non-Linux ports at this stage ? We will require sysvinit support through the jessie release. Post jessie, my preference would be to say that support for the init system used by non-Linux ports should be treated the same way as any other porting issue to the non-Linux ports, such as PATH_MAX issues with Hurd. In other words, those are normal bugs in packages unless the release team decides that a non-Linux port is a release architecture, maintainers should apply patches unless they're excessively intrusive, and maintainers aren't expected to test on those architectures. * What should be an RC bug in jessie ? * What should be an RC bug in jessie+1 ? I think we should (and possibly are required to) defer to the release team on RC bugs in particular, but I do think we should say that support for the default init system and for sysvinit are required for jessie (with the caveat about what required means for packages that rely on functionality not provided by sysvinit). I also think we need to answer: * What level of dysfunction is OK if an application (or a desktop environment or whatever) isn't running on its preferred pid 1 ? I think this depends a lot on whether the package is something significant enough that we would consider it to be a release blocker or whether it is an edge package, and whether the package is directly related to the init system or is unrelated. For example, were someone to want to package a variety of neat daemon management tools for OpenRC, I don't see any reason why that should be prohibited from the archive even if it requires OpenRC to run. And while I think it's a little weird to have some application in the archive that's packaged so that it will only work with a non-default init, as long as it declares that dependency in some reasonable way (that doesn't result in the system being switched to that init system when it's installed), I have a hard time seeing exactly what it *hurts* to have it in the archive. I think that major packages that would be considered release blockers, which probably includes GNOME, KDE, and Xfce, need to support the default Linux init system in the sense that, if they don't, I don't think we can release. I think a substantial degredation of functionality when running on an init system other than the Linux default would be okay for for jessie+1. For jessie, I think it depends greatly on how feasible making them work with sysvinit is (and I suspect sysvinit support would be sufficient for all other purposes). * Do we want to give any guidance about what a maintainer may consider an unreasonable native-init-system-support patch ? Or to put it another way, do we intend to overrule a maintainer who declines to implement one (or any) non-forking startup protocol ? This is hard. I'm not sure. I'm leaning towards not getting into this. -- 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: Init system resolution open questions
On Thu, Jan 16, 2014 at 09:39:37PM +0100, Ansgar Burchardt wrote: ... Maintainers only should not drop support for a (default) init system when the application supports it. ... So if udev (maintained by systemd upstream as part of the systemd sources) would ever get a dependency on systemd being the init system,[1] that should be fine even when the decision of Debian was to support multiple init systems? Ansgar cu Adrian [1] I am not assuming bad faith by systemd upstream. But if there ever is a technical advantage in making udev depending on systemd being pid 1, it might be a reasonable option for systemd upstream to add such a hard dependency to udev. -- 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: Init system resolution open questions
Hi, Adrian Bunk b...@stusta.de writes: On Thu, Jan 16, 2014 at 09:39:37PM +0100, Ansgar Burchardt wrote: ... Maintainers only should not drop support for a (default) init system when the application supports it. ... So if udev (maintained by systemd upstream as part of the systemd sources) would ever get a dependency on systemd being the init system,[1] that should be fine even when the decision of Debian was to support multiple init systems? If it doesn't work at all without systemd enabled, yes. Note that this doesn't stop people from keeping it working without systemd in which case it wouldn't need this dependency. Having already existing packages gain a dependency on a specific init system is probably more controverse and more people might want to avoid that[1], but that is (IMHO) no reason to forbid such dependencies altogether. Ansgar [1] That's why there was a footnote in my earlier mail. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
