Bug#727708: systemd jessie - jessie+1 upgrade problems
On Thu, Dec 19, 2013 at 11:26:19PM +0100, Josselin Mouette wrote: Le jeudi 19 décembre 2013 à 12:35 -0800, Steve Langasek a écrit : The reasons for not upgrading to the current version of logind aren't to do with any fragility of the existing glue code (the systemd-shim package), but because logind 205 has a new dependency on systemd as cgroup manager, which is architecturally incompatible with other consumers of cgroups in the ecosystem. This needs to be resolved before logind v205 can reasonably be adopted, because it's broken by design and needs to be worked around. The new logind is not “broken by design”. Using the cgroups tree is the most correct and secure way to identify which processes are permitted to access specific devices or services. You might disagree with the idea of a single cgroups manager or prefer a less secure mechanism in order to handle corner cases (that have yet to be described), but that doesn’t make the design less correct. The design which claims this role for systemd-as-pid-1, and which does not adequately address use cases of other existing cgroups consumers in the ecosystem (lmctfy, lxc) is broken by design. Having a single cgroup writer in userspace is fine. Coupling it to systemd in this manner is not. -- 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: systemd as cgroup writer (was: Bug#727708: systemd jessie - jessie+1 upgrade problems)
* Steve Langasek (vor...@debian.org) [131220 16:57]: The design which claims this role for systemd-as-pid-1, and which does not adequately address use cases of other existing cgroups consumers in the ecosystem (lmctfy, lxc) is broken by design. Having a single cgroup writer in userspace is fine. Coupling it to systemd in this manner is not. I would like to understand that topic further, so I have two questions (to different people): 1. Does systemd (or a part of the systemd project) need to be the single cgroup writer and if so, why? 2. What problems do arise from there for other parts of the linux ecosystem? Andi -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131221074810.ge16...@mails.so.argh.org
Bug#727708: systemd jessie - jessie+1 upgrade problems
On Thu, Dec 19, 2013 at 09:43:05AM +0200, Adrian Bunk wrote: On Wed, Dec 18, 2013 at 02:53:39PM -0800, Russ Allbery wrote: Adrian Bunk b...@stusta.de writes: [1] Personally, I am sceptical whether it is a good idea to switch to a different init system for jessie. But I am not on a desperate rant against systemd, and if something I bring up can be addressed that is positive for me. Just to give fair warning: right now, based on what I know today, there is basically zero chance that I personally will vote retaining sysvinit for jessie above further discussion. So if you want to convince at least this one member of the technical committee that this is a viable option, you have quite a bit of work to do. Where would further discussion in 1-2 years rank for you? What I suggested earlier in this discussion was not that you vote for keeping sysvinit forever, but: * jessie will continue to use sysvinit, and the TC will re-evaluate the situation after the release of jessie This is equivalent to let others outside of Debian decide our course for us. The Linux ecosystem won't stand still waiting for Debian to make a decision; if Debian doesn't take a decision this cycle, Upstart will remain a single-distro solution in the eyes of many, which means systemd will retain its upstream soapbox and continue to gather contributors. Russ rightly points out that there is a momentum gap between systemd and upstart. It is not insurmountable, if Debian decides to endorse upstart today. But two years further on, it will be. If Debian wants to replace sysvinit with something modern, and wants a say in what that replacement will be, it should decide now. And if Debian's not going to adopt upstart, then we should adopt systemd immediately so that we have a say in its direction between now and jessie, instead of waiting until after jessie and finding ourselves with two more years of entrenched bugs / design problems to sort out when integrating with it. -- 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 -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131219172453.gb24...@virgil.dodds.net
Bug#727708: systemd jessie - jessie+1 upgrade problems
Adrian Bunk b...@stusta.de writes: Ubuntu is also using udev and logind without using systemd, so they are and will continue to be available stand-alone. Ubuntu is maintaining a variety of moderately fragile glue in order to make this happen and currently can't upgrade to the current version of logind. This strategy clearly causes some problems for Ubuntu and would cause some similar problems for us. I think everyone agrees that it's *possible*, but my point is that it's increased work that we otherwise wouldn't have to incur. And having them standalone and not as part of the big systemd bundle makes it much easier to ship an older version of udev and/or logind in a release if that avoids upgrade headaches. This proven false by the way that Debian already handles gcc, many library transitions, and multiple other packages where we build different components from different versions for backwards-compatibility reasons. This is not difficult to handle at the packaging layer if we need to do it. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bo0cd8xu@windlord.stanford.edu
Bug#727708: systemd jessie - jessie+1 upgrade problems
On Thu, Dec 19, 2013 at 09:53:01AM -0800, Russ Allbery wrote: Adrian Bunk b...@stusta.de writes: Ubuntu is also using udev and logind without using systemd, so they are and will continue to be available stand-alone. Ubuntu is maintaining a variety of moderately fragile glue in order to make this happen and currently can't upgrade to the current version of logind. The reasons for not upgrading to the current version of logind aren't to do with any fragility of the existing glue code (the systemd-shim package), but because logind 205 has a new dependency on systemd as cgroup manager, which is architecturally incompatible with other consumers of cgroups in the ecosystem. This needs to be resolved before logind v205 can reasonably be adopted, because it's broken by design and needs to be worked around. This strategy clearly causes some problems for Ubuntu and would cause some similar problems for us. I think everyone agrees that it's *possible*, but my point is that it's increased work that we otherwise wouldn't have to incur. I wouldn't call this a problem, so much as the cost of integrating an OS. systemd-shim weighs in at 2kloc of C code, and is relatively stable. An out-of-pid-1 cgroup manager will bring more code to the table, but only that which is necessary to support systemd-incompatible uses of cgroups. systemd-shim will need extended to bridge between cgmanager and logind. Yes, there's code here that wouldn't need to be written if we all just adopted systemd. But the hidden assumption there is that systemd adequately addresses all the use cases we care about. When you want to support something that upstream doesn't want to support, you get to write code. It seems to me that most of this code would have to be written to support logind on non-Linux anyway, and is a much better choice than supporting consolekit indefinitely for those ports. -- 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: systemd jessie - jessie+1 upgrade problems
Le jeudi 19 décembre 2013 à 12:35 -0800, Steve Langasek a écrit : The reasons for not upgrading to the current version of logind aren't to do with any fragility of the existing glue code (the systemd-shim package), but because logind 205 has a new dependency on systemd as cgroup manager, which is architecturally incompatible with other consumers of cgroups in the ecosystem. This needs to be resolved before logind v205 can reasonably be adopted, because it's broken by design and needs to be worked around. The new logind is not “broken by design”. Using the cgroups tree is the most correct and secure way to identify which processes are permitted to access specific devices or services. You might disagree with the idea of a single cgroups manager or prefer a less secure mechanism in order to handle corner cases (that have yet to be described), but that doesn’t make the design less correct. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1387491979.21380.15.camel@tomoe
Bug#727708: systemd jessie - jessie+1 upgrade problems
On Tue, Dec 17, 2013 at 06:02:50PM -0500, Sam Hartman wrote: Adrian == Adrian Bunk b...@stusta.de writes: Adrian Yes, it is speculation that other new features (or even Adrian bugfixes) might appear in the kernel and might become Adrian mandatory in systemd between jessie and jessie+1. Adrian But that is a risk, and it is a risk that is unique to the Adrian systemd option since none of the alternatives is Adrian Linux-only. [2] Adrian My whole point is not about kdbus specifically (which might Adrian even end up in the jessie kernel), but about that (IMHO Adrian substantial) risk. I'm confused, when I hear you say that this risk is unique to the systemd option and not shared by other options. I would understand that statement if we thought we could avoid systemd entirely. It sounds like we may be able to avoid systemd as pid 1 but systemd is very likely to play an important role in the Debian desktop storpy even if we adopt another pid 1. It seems like if systemd starts depending on a new kernel feature then it might well need that feature even when not running as pid 1. So, when evaluating the opportunity costs of this risk in the pid 1 debate it seems like there are two important mitigating circumstances: * The extent to which upstream will provide stability, reducing the risk * The extent to which we cannot avoid the risk even if we choose another pid 1, reducing the portion of the cost of this risk properly in-scope for this bug. Thanks for the explanation, and apologies to Josselin and Russ that I completely misread their point regarding udev: I was misreading that as referring to the headaches udev had caused in the past for Debian upgrades, not that the systemd udev might be the cause of future upgrade headaches. But I do not buy this We already switched to systemd as upstream of udev, so we also have swallow the rest of it: When not using systemd as pid 1, that risk would be confined to the parts of systemd Debian would be using (currently only udev). And since Ubuntu will also be in the no systemd and supports upgrades from 2 year old releases camp, chances are that there would be solutions available that Debian could use. As an example, if the systemd udev gets a hard dependency on a too recent kernel or on systemd internals, there might be a fork of udev that provides a standalone udev that is suitable for Ubuntu and Debian. ... At some level, we also need to be community players. Since upgrade stability is important to us, we should advocate for it in open-source projects that we depend on. On the flip side, if enough of the rest of the community after having carefully considered our arguments decides that our desire for stability is too expensive, perhaps we need to reconsider our position. I hope we don't need to do that, but sometimes when enough of the rest of the world disagrees with you, you need to move on. That point you bring up is semi-orthogonal to the upgrade decision, but it also brings up two important points that have to be considered: 1. What is the governance model of the systemd community? This might be a bit polemic, but I'd fear that your enough of the rest of the community after having carefully considered our arguments decides might end up being the same as if Lennart decides it does not match his vision of how things should work. This is a real issue since systemd is attempting to absorb a lot of essential Linux functionality, giving whoever makes the decisions in systemd a lot of power over policies affecting all distributions using systemd. And 2. Does anyone have a complete overview of what Debian policies might have to be changed now or possibly at some later time as a result of making systemd pid 1? systemd does not support non-Linux kernels [1], and realistically using systemd as pid 1 in jessie will kill all non-Linux ports of Debian. [2] systemd upstream only reluctantly supports the option to have a separate /usr (as currently mandated by Debian policy), and I would not be surprised if that gets dropped any time if it becomes an obstacle for development of any part of systemd. And now you bring up the point that Debian should reconsider the lenght of it's release cycles if systemd upstream decides to not support upgrades between distribution releases as far apart as Debian's. [3] There are likely more areas where Debian would have to adapt if using systemd. The more I think about it, the more I wish the TC would decide: * jessie will continue to use sysvinit, and the TC will re-evaluate the situation after the release of jessie Rationale: - as time passes, the kernel-systemd interface will become more stable [4], reducing potential upgrade problems and - the full consequences of a switch to systemd on various areas of Debian will become more clear cu Adrian [1] which is not an unreasonable design decision
Bug#727708: systemd jessie - jessie+1 upgrade problems
Hi Adrian, Le mercredi 18 décembre 2013 à 13:34 +0200, Adrian Bunk a écrit : That point you bring up is semi-orthogonal to the upgrade decision, but it also brings up two important points that have to be considered: 1. What is the governance model of the systemd community? This might be a bit polemic, but I'd fear that your enough of the rest of the community after having carefully considered our arguments decides might end up being the same as if Lennart decides it does not match his vision of how things should work. This is a red herring that has been recurrently agitated, on the basis of the PulseAudio experience, but so far it has never proven to have any basis in reality. Just because Lennart is a developer in both projects, doesn’t mean they have the same governance model. Systemd’s development is driven by the needs of its users. It has even incorporated a lot of Debian’s needs, despite our choice so far to delay its inclusion. It has used some of Debian’s good practices (e.g. /etc/hostname or /etc/timezone) as a basis for standardization across other distributions. This is a real issue since systemd is attempting to absorb a lot of essential Linux functionality, giving whoever makes the decisions in systemd a lot of power over policies affecting all distributions using systemd. Things work the other way round. Debian will have more weight in the future of systemd if we adopt it. It is unreasonable to ask an upstream project to conform to your policies if you don’t even use it. We need to play with the community: embrace systemd, and use that weight in the decisions affecting its future. Let’s consider the kdbus example in this light. If Debian is a major systemd player, it is more likely that upstream will support a fallback to the old dbus-daemon until a kdbus-enabled kernel makes it to a stable Debian release, or at least makes it easier for us to maintain that fallback. If Debian does not pick systemd, what is the point for upstream in making their software more complex for the benefit of nobody? Maybe it will not work. Maybe the cost for upstream will be too high regardless. I might have to remind you that the sarge→etch upgrade had a locked-in upgrade of udev and the kernel. The world did not crumble, and we didn’t abandon our policies just because we had to make an exception. (Actually this upgrade was much smoother than the python shit in squeeze→wheezy.) We made it work that time, and if, despite our efforts, we have to make another exception, we will make it work again. Leaving out important features until a hypothetical date, just because we fear our own skills and ability to provide smooth upgrades, doesn’t sound like a great plan to me. systemd upstream only reluctantly supports the option to have a separate /usr (as currently mandated by Debian policy), and I would not be surprised if that gets dropped any time if it becomes an obstacle for development of any part of systemd. This is another red herring. The Debian code to support a split /usr by mounting it from the initrd is simple, and not likely to be broken by any new developments. I see much irony in seeing people fear for non-Linux ports, for one of which we have maintained easy patches for years allowing for a merged /usr, and at the same time argue that maintaining a split /usr for Linux will be hard. And now you bring up the point that Debian should reconsider the lenght of it's release cycles if systemd upstream decides to not support upgrades between distribution releases as far apart as Debian's. [3] Well, of course we should reconsider the length of our release cycle (and make it 3 years like major OS players do), but this is irrelevant to the choice of an init system. The more I think about it, the more I wish the TC would decide: * jessie will continue to use sysvinit, and the TC will re-evaluate the situation after the release of jessie This option does not look realistic to me. At least the upstart proponents have outlined a strategy to keep software depending on systemd interfaces working in jessie. Cheers, -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1387369188.8542.119.camel@dsp0698014
Bug#727708: systemd jessie - jessie+1 upgrade problems
On Wed, 2013-12-18 at 13:34 +0200, Adrian Bunk wrote: On Tue, Dec 17, 2013 at 06:02:50PM -0500, Sam Hartman wrote: I'm confused, when I hear you say that this risk is unique to the systemd option and not shared by other options. I would understand that statement if we thought we could avoid systemd entirely. It sounds like we may be able to avoid systemd as pid 1 but systemd is very likely to play an important role in the Debian desktop storpy even if we adopt another pid 1. Thanks for the explanation, and apologies to Josselin and Russ that I completely misread their point regarding udev: I was misreading that as referring to the headaches udev had caused in the past for Debian upgrades, not that the systemd udev might be the cause of future upgrade headaches. But I do not buy this We already switched to systemd as upstream of udev, so we also have swallow the rest of it: When not using systemd as pid 1, that risk would be confined to the parts of systemd Debian would be using (currently only udev). I think you still misread the argument: IMO it's clear that it considered more than udev as likely to be required, even if udev is the only one in current Debian. So if you disagree, you should at least address the question of why you believe udev will stay the only one. At some level, we also need to be community players. Since upgrade stability is important to us, we should advocate for it in open-source projects that we depend on. On the flip side, if enough of the rest of the community after having carefully considered our arguments decides that our desire for stability is too expensive, perhaps we need to reconsider our position. I hope we don't need to do that, but sometimes when enough of the rest of the world disagrees with you, you need to move on. systemd upstream only reluctantly supports the option to have a separate /usr (as currently mandated by Debian policy), and I would not be surprised if that gets dropped any time if it becomes an obstacle for development of any part of systemd. You're mixing two separate issues (or at least not clearly indicating which one you're talking about). Systemd fully supports having a separate /usr partition, and that is in no way deprecated AFAIK. What has changed compared to old practice is that /usr needs to be mounted together with root (requiring initramfs if you have a separate /usr; where you had mount / before you now have mount / and /usr). Whether the old way of later /usr mounting could keep working with any other init either is questionable. Then there is the move of binaries from /bin to /usr/bin, which does have some backwards compatibility logic for different paths in systemd. This is not directly connected to /usr being a separate partition or not (but having everything in /usr/bin obviously requires /usr mounted early). Does someone in Debian seriously oppose this move as a long term goal? And now you bring up the point that Debian should reconsider the lenght of it's release cycles if systemd upstream decides to not support upgrades between distribution releases as far apart as Debian's. [3] I don't think anyone said that. Nobody talked about long release cycles not being supported, and nobody said that upgrades would not be supported either. However, supporting upgrade from the old release does not equal things like being able to run the new userland on the 3+ year old kernel from the previous release. A development model where you have to wait 3+ years before you can have hard dependencies on the new features you write now is obviously very problematic. IMO such restraints should never be taken for granted; upgrade schemes should always be planned to at least make it possible to have newer dependencies without too much trouble. In the kdbus case, systemd upstream already mentioned the possibility of shipping kdbus as a new module for older kernels. More generally, you can have solutions like applying some upgrades at boot rather than trying to switch parts from under a fully live system. This does still count as fully supporting upgrades. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1387372219.3938.46.camel@glyph.nonexistent.invalid
Bug#727708: systemd jessie - jessie+1 upgrade problems
On Wed, Dec 18, 2013 at 03:10:19PM +0200, Uoti Urpala wrote: In the kdbus case, systemd upstream already mentioned the possibility of shipping kdbus as a new module for older kernels. More generally, you can have solutions like applying some upgrades at boot rather than trying to switch parts from under a fully live system. This does still count as fully supporting upgrades. You might think so. To me, that sounds like a hacky workaround for needlessly inflexible software. Much like Windows. -- Steve McIntyre, Cambridge, UK.st...@einval.com The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary. -- James D. Nicoll -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131218132425.ga...@einval.com
Bug#727708: systemd jessie - jessie+1 upgrade problems
Adrian, I'm frustrated when I read your message because you put words in my mouth that I did not speak. I never said that Debian should allow systemd to dictate policy for multiple distributions nor did I say that Debian should allow one upstream systemd maintainer to dictate decisions for Debian. I spoke of community both in terms of a systemd community and in terms of a community of Linux distributions. You may believe that some of these boil down to the same thing. I request that you distinguish what you believe is a conclusion from things I've said from the things I actually say. Thanks, --Sam -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/tsleh5auuyn@mit.edu
Bug#727708: systemd jessie - jessie+1 upgrade problems
]] Uoti Urpala In the kdbus case, systemd upstream already mentioned the possibility of shipping kdbus as a new module for older kernels. More generally, you can have solutions like applying some upgrades at boot rather than trying to switch parts from under a fully live system. This does still count as fully supporting upgrades. I have no intention of implementing an upgrade-on-boot scheme in the systemd package. One of the many problems with such a scheme is that recovery becomes much harder, since your system no longer boots and you don't have a working shell or network or anything at that point. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m261qm1bzu@rahvafeir.err.no
Bug#727708: systemd jessie - jessie+1 upgrade problems
On Wed, Dec 18, 2013 at 01:19:48PM +0100, Josselin Mouette wrote: Hi Adrian, Hi Josselin, Le mercredi 18 décembre 2013 à 13:34 +0200, Adrian Bunk a écrit : That point you bring up is semi-orthogonal to the upgrade decision, but it also brings up two important points that have to be considered: 1. What is the governance model of the systemd community? This might be a bit polemic, but I'd fear that your enough of the rest of the community after having carefully considered our arguments decides might end up being the same as if Lennart decides it does not match his vision of how things should work. This is a red herring that has been recurrently agitated, on the basis of the PulseAudio experience, but so far it has never proven to have any basis in reality. Just because Lennart is a developer in both projects, doesn’t mean they have the same governance model. the *so far* is the worrisome part, considering how much power to enforce policy whoever controls systemd has. Switching to systemd also implies to trust that Lennart will do the right things. I am not in a position to judge whether or not Lennart should be trusted, but everyone should be aware that this trust in Lennart is a requirement for a switch to systemd. ... Maybe it will not work. Maybe the cost for upstream will be too high regardless. I might have to remind you that the sarge→etch upgrade had a locked-in upgrade of udev and the kernel. The world did not crumble, and we didn’t abandon our policies just because we had to make an exception. (Actually this upgrade was much smoother than the python shit in squeeze→wheezy.) We made it work that time, and if, despite our efforts, we have to make another exception, we will make it work again. We already seem to agree that the statement in the systemd position statement that does not have any impact on the ability to upgrade systems is not correct. There might potentially be non-trivial jessie - jessie+1 upgrade problems with systemd, and even though such issues will likely be work-aroundable with an unknown amount of effort, they are something to take into consideration. Leaving out important features until a hypothetical date, What exactly is the list of features that are lost as of today if Debian uses in jessie the logind from the systemd 204 package in unstable and perhaps work Ubuntu has done for a non-systemd system? This won't solve the issue long-term, but it would give us 2 more years to observe how the whole init system situation develops. systemd upstream only reluctantly supports the option to have a separate /usr (as currently mandated by Debian policy), and I would not be surprised if that gets dropped any time if it becomes an obstacle for development of any part of systemd. This is another red herring. The Debian code to support a split /usr by mounting it from the initrd is simple, and not likely to be broken by any new developments. Are you saying that Debian will not use the --enable-split-usr configure option of systemd, and therefore won't have to change policy if it ever goes away? I see much irony in seeing people fear for non-Linux ports, for one of which we have maintained easy patches for years allowing for a merged /usr, and at the same time argue that maintaining a split /usr for Linux will be hard. See my question above. On a general note, neither non-Linux kernels nor a split /usr are something I consider extremely important myself. But these are examples for policy decisions that might be caused by a switch to systemd. And now you bring up the point that Debian should reconsider the lenght of it's release cycles if systemd upstream decides to not support upgrades between distribution releases as far apart as Debian's. [3] Well, of course we should reconsider the length of our release cycle (and make it 3 years like major OS players do), You miss the critical difference: Red Hat does not support upgrades between major releases of their enterprise distribution. but this is irrelevant to the choice of an init system. It is not, when the init system might cause upgrade problems. The more I think about it, the more I wish the TC would decide: * jessie will continue to use sysvinit, and the TC will re-evaluate the situation after the release of jessie This option does not look realistic to me. See my question on that issue above. At least the upstart proponents have outlined a strategy to keep software depending on systemd interfaces working in jessie. The worst case would be that Debian switches init systems in jessie (e.g. to upstart) and then again in jessie+1 (e.g. if systemd then turns out to be the best solution, or if Canonical abandons upstart). 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
Bug#727708: systemd jessie - jessie+1 upgrade problems
On Wed, Dec 18, 2013 at 08:53:04AM -0500, Sam Hartman wrote: Adrian, I'm frustrated when I read your message because you put words in my mouth that I did not speak. Hi Sam, I never said that Debian should allow systemd to dictate policy for multiple distributions nor did I say that Debian should allow one upstream systemd maintainer to dictate decisions for Debian. I assume you are referring to That point you bring up is semi-orthogonal to the upgrade decision, but it also brings up two important points that have to be considered: The second line was not intended to imply that you said that, just very poorly worded by me. The second line might have been better worded like Possible problems I see when following this we also need to be community players: I spoke of community both in terms of a systemd community and in terms of a community of Linux distributions. The problematic parts are where Debian differs from other distributions. E.g. Debian has been the only big Linux distribution that did support non-Linux kernels. If Debian wants to be closely aligned to the consensus among other distributions it might have to drop non-Linux kernels, and switching to systemd basically enforces that. You may believe that some of these boil down to the same thing. I request that you distinguish what you believe is a conclusion from things I've said from the things I actually say. See above regarding my poor wording. Thanks, --Sam 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-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131218144915.gw30...@bunk.dyndns.info
Bug#727708: systemd jessie - jessie+1 upgrade problems
On Wed, Dec 18, 2013 at 04:26:44PM +0200, Adrian Bunk wrote: the *so far* is the worrisome part, considering how much power to enforce policy whoever controls systemd has. Switching to systemd also implies to trust that Lennart will do the right things. I am not in a position to judge whether or not Lennart should be trusted, but everyone should be aware that this trust in Lennart is a requirement for a switch to systemd. Firstly, we don't have to trust Lennart, we have to trust the team working on systemd. I believe there to be a distinction there, and I do trust that team won't break all the systemdistros to get their jollies. Secondly, systemd is free software. If and when systemd diverges from what we need it to do, we can consider a fork. I don't want a fork, and I'm willing to bet the systemd folks won't either. It's not like we're locked into whatever Lennart decides. Cheers, Paul -- .''`. 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: systemd jessie - jessie+1 upgrade problems
Hi, Le mercredi 18 décembre 2013 à 16:26 +0200, Adrian Bunk a écrit : We already seem to agree that the statement in the systemd position statement that does not have any impact on the ability to upgrade systems is not correct. No, we do not. I have already explained why I believe the kdbus question (and maybe similar ones) will arise whether we switch to systemd or not. I do not consider keeping an arbitrary number of packages at the wheezy version an appropriate answer, regardless of the choice of init systems. You also deliberately omitted to quote the part where I explained why this is less likely to happen if we actually become part of the systemd community instead of judging their work on our standards. What exactly is the list of features that are lost as of today if Debian uses in jessie the logind from the systemd 204 package in unstable and perhaps work Ubuntu has done for a non-systemd system? Quoting myself from the debate page: “Many discussions are centered on systemd-logind as in being the only problem to address by other proposals, wildly proposing seemingly easy-to-develop replacements.” If you have other questions relevant for the discussion at hand, please go ahead, but I will not jump into arguments running in circles. We systemd proponents have spent a lot of time summing up the functional reasons why we want systemd on our Debian systems, with logind being one reason among dozens; you could have read them before asking the same question again. -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1387378233.8542.141.camel@dsp0698014
Bug#727708: systemd jessie - jessie+1 upgrade problems
Hi, Adrian Bunk b...@stusta.de writes: On Wed, Dec 18, 2013 at 01:19:48PM +0100, Josselin Mouette wrote: And now you bring up the point that Debian should reconsider the lenght of it's release cycles if systemd upstream decides to not support upgrades between distribution releases as far apart as Debian's. [3] Well, of course we should reconsider the length of our release cycle (and make it 3 years like major OS players do), You miss the critical difference: Red Hat does not support upgrades between major releases of their enterprise distribution. Except they do: Red Hat Enterprise Linux 7 will offer an in-place upgrade feature for common server deployment types, allowing data centers to migrate existing Red Hat Enterprise Linux 6.5 systems to Red Hat Enterprise Linux 7[1]. Ansgar [1] http://www.redhat.com/about/news/archive/2013/12/red-hat-announces-availability-of-red-hat-enterprise-linux-7-beta -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bo0edwkk@marvin.43-1.org
Bug#727708: systemd jessie - jessie+1 upgrade problems
On Wed, Dec 18, 2013 at 03:10:19PM +0200, Uoti Urpala wrote: On Wed, 2013-12-18 at 13:34 +0200, Adrian Bunk wrote: ... When not using systemd as pid 1, that risk would be confined to the parts of systemd Debian would be using (currently only udev). I think you still misread the argument: IMO it's clear that it considered more than udev as likely to be required, even if udev is the only one in current Debian. So if you disagree, you should at least address the question of why you believe udev will stay the only one. I think you misread what I wrote. I wrote part*s* of systemd, and that *currently* udev is the only one. At some level, we also need to be community players. Since upgrade stability is important to us, we should advocate for it in open-source projects that we depend on. On the flip side, if enough of the rest of the community after having carefully considered our arguments decides that our desire for stability is too expensive, perhaps we need to reconsider our position. I hope we don't need to do that, but sometimes when enough of the rest of the world disagrees with you, you need to move on. systemd upstream only reluctantly supports the option to have a separate /usr (as currently mandated by Debian policy), and I would not be surprised if that gets dropped any time if it becomes an obstacle for development of any part of systemd. You're mixing two separate issues (or at least not clearly indicating which one you're talking about). Systemd fully supports having a separate /usr partition, and that is in no way deprecated AFAIK. What has changed compared to old practice is that /usr needs to be mounted together with root Thanks for the clarification, I missed that this useful part of having a separate /usr (mounting it later) is already broken with systemd. Whether the old way of later /usr mounting could keep working with any other init either is questionable. I am not seeing any reason why it should suddenly stop working with sysvinit. A development model where you have to wait 3+ years before you can have hard dependencies on the new features you write now is obviously very problematic. IMO such restraints should never be taken for granted; upgrade schemes should always be planned to at least make it possible to have newer dependencies without too much trouble. For normal dependencies there is no such restraint. Only when the dependency is on a new kernel there is a problem and the upgrade becomes complicated. cu Adrian BTW: Please Cc me on replies - even though I am subscribed to the bug, I don't seem to get the mails. -- 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-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131218152322.gx30...@bunk.dyndns.info
Bug#727708: systemd jessie - jessie+1 upgrade problems
On Wed, Dec 18, 2013 at 04:10:19PM +0100, Ansgar Burchardt wrote: Hi, Adrian Bunk b...@stusta.de writes: On Wed, Dec 18, 2013 at 01:19:48PM +0100, Josselin Mouette wrote: And now you bring up the point that Debian should reconsider the lenght of it's release cycles if systemd upstream decides to not support upgrades between distribution releases as far apart as Debian's. [3] Well, of course we should reconsider the length of our release cycle (and make it 3 years like major OS players do), You miss the critical difference: Red Hat does not support upgrades between major releases of their enterprise distribution. Except they do: Red Hat Enterprise Linux 7 will offer an in-place upgrade feature for common server deployment types, allowing data centers to migrate existing Red Hat Enterprise Linux 6.5 systems to Red Hat Enterprise Linux 7[1]. That is good news (RHEL5-RHEL6 was not supported). If anyone finds (or asks) what backwards compatibility future systemd versions will offer with 3 year old kernels that would settle my initial upgrade issue point. [1] Ansgar cu Adrian [1] Personally, I am sceptical whether it is a good idea to switch to a different init system for jessie. But I am not on a desperate rant against systemd, and if something I bring up can be addressed that is positive for me. -- 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-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131218154458.gy30...@bunk.dyndns.info
Bug#727708: systemd jessie - jessie+1 upgrade problems
On Wed, Dec 18, 2013 at 03:50:33PM +0100, Josselin Mouette wrote: Hi, Hi Josselin, ... I do not consider keeping an arbitrary number of packages at the wheezy version an appropriate answer, regardless of the choice of init systems. ... how many and which packages would have to be kept at the wheezy version if Debian does not switch to systemd? -- .''`.Josselin Mouette : :' : `. `' `- 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-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131218163109.gz30...@bunk.dyndns.info
Bug#727708: systemd jessie - jessie+1 upgrade problems
]] Adrian Bunk You're mixing two separate issues (or at least not clearly indicating which one you're talking about). Systemd fully supports having a separate /usr partition, and that is in no way deprecated AFAIK. What has changed compared to old practice is that /usr needs to be mounted together with root Thanks for the clarification, I missed that this useful part of having a separate /usr (mounting it later) is already broken with systemd. No, it's not. systemd will emit a warning that some services might be broken because of this, systemd itself works just fine. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m2y53hzz0b@rahvafeir.err.no
Re: Bug#727708: systemd jessie - jessie+1 upgrade problems
]] Josselin Mouette It is possible to handle the situation with udev or with systemd, because they do not make sense in a chroot environment, but they are the exception, not the rule. And unless things go hectic, we *will* be able to treat them normally and provide an upgrade path that doesn’t force users to do locked upgrades. We need systemd in the chroot if we want to support containers through mechanisms such as systemd-nspawn. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m2txe5zy4l@rahvafeir.err.no
Bug#727708: systemd jessie - jessie+1 upgrade problems
Adrian Bunk b...@stusta.de writes: I was misreading that as referring to the headaches udev had caused in the past for Debian upgrades, not that the systemd udev might be the cause of future upgrade headaches. But I do not buy this We already switched to systemd as upstream of udev, so we also have swallow the rest of it: I don't think anyone is making that argument. However, there is a valid related argument that, since we're already using much of systemd, our integrations will be easier if we also use systemd as the init system. I don't think anyone considers that single argument alone to be conclusive, but it's relevant. Note that one can make, and people have made, an argument that we should intentionally make our integrations harder if by doing so we can weaken coupling between subsystems that we feel should be unrelated. I'm not intending to comment on that argument in this message, just to note that it isn't a counterargument to the point above, but rather an argument about relative priority. It's saying that a different goal -- weak coupling -- is more important than reduced Debian integration workload. When not using systemd as pid 1, that risk would be confined to the parts of systemd Debian would be using (currently only udev). There appears to be near-unanimous agreement that Debian will also be using logind in the near future. I think only in this context is misleading, given that the components we're going to be using anyway (including kdbus in this; if it's included in the kernel, I highly doubt Debian will refuse to use it in the long run) are pretty much the same components that people are concerned about being unstable. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lhzhsrt8@windlord.stanford.edu
Bug#727708: systemd jessie - jessie+1 upgrade problems
Adrian Bunk b...@stusta.de writes: [1] Personally, I am sceptical whether it is a good idea to switch to a different init system for jessie. But I am not on a desperate rant against systemd, and if something I bring up can be addressed that is positive for me. Just to give fair warning: right now, based on what I know today, there is basically zero chance that I personally will vote retaining sysvinit for jessie above further discussion. So if you want to convince at least this one member of the technical committee that this is a viable option, you have quite a bit of work to do. Right now, it appears to me that the feature set is wholly inadequate, further substantial development is highly unlikely, the configuration syntax is familiar but awful, and we are already seeing software in the archive that requires capabilities that it's just not able to support. To support continuing to use sysvinit, I think I would need to see a credible plan for significant upstream development and support of the software, including, at a minimum, how the features that are required by our desktop environments would be handled, how device management and dependencies will be managed given the event-driven kernel, and how proper daemon management at least at the level common to upstart, systemd, and OpenRC will be added. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87haa5srd8@windlord.stanford.edu
Bug#727708: systemd jessie - jessie+1 upgrade problems
On Wed, Dec 18, 2013 at 02:44:03PM -0800, Russ Allbery wrote: Adrian Bunk b...@stusta.de writes: ... When not using systemd as pid 1, that risk would be confined to the parts of systemd Debian would be using (currently only udev). There appears to be near-unanimous agreement that Debian will also be using logind in the near future. I think only in this context is misleading, given that the components we're going to be using anyway (including kdbus in this; if it's included in the kernel, I highly doubt Debian will refuse to use it in the long run) are pretty much the same components that people are concerned about being unstable. I expect Debian to use kdbus in the long run if it gets accepted into the upstream kernel in any case. Note that this does not imply that Debian has to switch to systemd. Ubuntu is also using udev and logind without using systemd, so they are and will continue to be available stand-alone. And having them standalone and not as part of the big systemd bundle makes it much easier to ship an older version of udev and/or logind in a release if that avoids upgrade headaches. Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ 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-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131219072227.ge30...@bunk.dyndns.info
Bug#727708: systemd jessie - jessie+1 upgrade problems
On Wed, Dec 18, 2013 at 02:53:39PM -0800, Russ Allbery wrote: Adrian Bunk b...@stusta.de writes: [1] Personally, I am sceptical whether it is a good idea to switch to a different init system for jessie. But I am not on a desperate rant against systemd, and if something I bring up can be addressed that is positive for me. Just to give fair warning: right now, based on what I know today, there is basically zero chance that I personally will vote retaining sysvinit for jessie above further discussion. So if you want to convince at least this one member of the technical committee that this is a viable option, you have quite a bit of work to do. Where would further discussion in 1-2 years rank for you? What I suggested earlier in this discussion was not that you vote for keeping sysvinit forever, but: * jessie will continue to use sysvinit, and the TC will re-evaluate the situation after the release of jessie As time passes, the kernel-systemd interface will become more stable since new features systemd wants like kdbus will already be in the kernel, reducing potential upgrade problems. It will also become more clear how exactly systemd is evolving and what exactly the consequences are for Debian in areas where Debian differs from other distributions. And in my opinion the worst case would be that Debian switches init systems in jessie and then again in jessie+1. OpenRC looks too WIP and with an unclear future for me for switching to it for jessie. Upstart is mature, but I would be cautious since Canonical might decide at some point in the future that systemd is better and abandon upstart. I am not seeing a big probability of that happening, but it is a risk. If you are convinced that any of systemd/OpenRC/upstart is the best option for Debian then vote for it, but no matter where you vote further discussion it is unlikely that there will be significant new arguments in the immediate future - and it would therefore be better to wait 1-2 years until the further discussion happens. Right now, it appears to me that the feature set is wholly inadequate, further substantial development is highly unlikely, the configuration syntax is familiar but awful, and we are already seeing software in the archive that requires capabilities that it's just not able to support. To support continuing to use sysvinit, I think I would need to see a credible plan for significant upstream development and support of the software, including, at a minimum, how the features that are required by our desktop environments would be handled, how device management and dependencies will be managed given the event-driven kernel, and how proper daemon management at least at the level common to upstart, systemd, and OpenRC will be added. When staying with sysvinit is only the stopgap solution for jessie, then significant upstream development would not even bring any advantages. Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ 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-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131219074305.gf30...@bunk.dyndns.info
Bug#727708: systemd jessie - jessie+1 upgrade problems
On Tue, Dec 17, 2013 at 10:29:35AM -0800, Russ Allbery wrote: Adrian Bunk b...@stusta.de writes: this hits exactly the core of the problem: The minimum supported Linux kernel version in glibc is currently 2.6.16, released in 2006. And I'd trust glibc upstreamt that this requirement won't suddenly be bumped to a quite recent version. Is there any explicit commitment from systemd upstream that releases of systemd releases around 2017 will still contain fallback code to work on kernels from 2013/2014? I'd really like to keep this bug and this discussion focused on what's relevant to Debian as a project, so let's put this in that perspective. The oldest kernel that Debian supports is 2.6.32, released in 2009. But the oldest kernel that we support for upgrades, which is the only point at which systemd backward compatibility matters for Debian's support model, is 3.2.0, released in 2012. Nitpick: 3.2.0 was released on January 5th 2012, so nearly 2011 The window of backward compatibility that we need is roughly a release cycle plus six months (due to the releases that miss the release window). That's much less than the seven years of the eglibc example. We explicitly don't need to worry about whether systemd in unstable works with the oldstable kernel since we don't support that degree of cross-release compatibility. If we're going to ask systemd upstream questions about this, we should use the actual time period that we care about (about two and a half to three years), not four years and certainly not seven years. I never talked about a seven years requirement, I was just listing the glibc status quo when Josselin said A notable similar example is eglibc. I agree with you that around 3 years is a reasonable estimate for what would be required from systemd. But without systemd Debian is free to make the decision when and how to adopt kdbus. If you add a systemd version that required kdbus into the mix, the upgrade becomes messy. That's only true to the extent that we can hold all other packages back, so it's true exactly to the degree that we can choose when and how to adopt kdbus if we standardized on systemd. If we're holding back upstream packages, we can hold back systemd as well. This situation doesn't change, which is Josselin's point. The holding back upstream packages would only be true for Linux-only software that additionally chooses to drop the non-kdbus codepaths. As I already explained, software like glib2.0 and libdbus that supports non-Linux kernels will anyway have to continue to support non-kdbus systems forever. Is there actually any implementation other than glib2.0 and libdbus that would be affected by a switch to kdbus? ... Maybe this was wrongly phrased: of course we should be concerned by compatibility at upgrade time. But using systemd doesn’t cause more compatibility problems than those we already have (e.g. with udev). The exact opposite it true. udev used to be the one package causing huge upgrade headaches back in it's early days when the ABI between udev and the kernel was changing. Later (at least until it was moved into systemd) it was mature and did not cause such problems. systemd is the former udev problems on steroids. I see no evidence to support this contention apart from a bunch of speculation on your part about what *might* happen four years in the future if particular features missed a release window. As an example, in the email from Josselin I was answering to he linked to an email from Lennart [1] that states: -- snip -- At the same time we will no longer support dbus-daemon for the system. This will add a hard dependency of systemd on a very new kernel version. However, to make this palatable we will try hard to keep kdbus.ko compilable out-of-tree and easily backportable. -- snip -- That is an explicit statement by upstream regarding what will happen in the near future. That makes it e.g. pretty clear that options 1. and 4. Josselin listed for a jessie - jessie+1 upgrade would definitely not be feasible if kdbus won't be in the jessie kernel. Yes, it is speculation that other new features (or even bugfixes) might appear in the kernel and might become mandatory in systemd between jessie and jessie+1. But that is a risk, and it is a risk that is unique to the systemd option since none of the alternatives is Linux-only. [2] My whole point is not about kdbus specifically (which might even end up in the jessie kernel), but about that (IMHO substantial) risk. Whether or not this risk exists at all should be settled by asking systemd upstream. If the answer is that for the required ~3 years period compatibility with older kernels is guaranteed, then please disregard my emails. Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ cu Adrian [1] http://lists.freedesktop.org/archives/systemd-devel/2013-March/009797.html
Bug#727708: systemd jessie - jessie+1 upgrade problems
Adrian Bunk b...@stusta.de writes: The holding back upstream packages would only be true for Linux-only software that additionally chooses to drop the non-kdbus codepaths. As I already explained, software like glib2.0 and libdbus that supports non-Linux kernels will anyway have to continue to support non-kdbus systems forever. Is there actually any implementation other than glib2.0 and libdbus that would be affected by a switch to kdbus? This is an interesting question. Josselin, is GNOME (for example) likely to acquire a hard dependency on kdbus through some mechanism? I don't understand the plumbing of this stuff well enough to know where the dependencies could surface. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871u1bql55@windlord.stanford.edu
Bug#727708: systemd jessie - jessie+1 upgrade problems
On Tue, Dec 17, 2013 at 09:38:56PM +0200, Adrian Bunk wrote: On Tue, Dec 17, 2013 at 10:29:35AM -0800, Russ Allbery wrote: Adrian Bunk b...@stusta.de writes: this hits exactly the core of the problem: The minimum supported Linux kernel version in glibc is currently 2.6.16, released in 2006. And I'd trust glibc upstreamt that this requirement won't suddenly be bumped to a quite recent version. Is there any explicit commitment from systemd upstream that releases of systemd releases around 2017 will still contain fallback code to work on kernels from 2013/2014? I'd really like to keep this bug and this discussion focused on what's relevant to Debian as a project, so let's put this in that perspective. The oldest kernel that Debian supports is 2.6.32, released in 2009. But the oldest kernel that we support for upgrades, which is the only point at which systemd backward compatibility matters for Debian's support model, is 3.2.0, released in 2012. Nitpick: 3.2.0 was released on January 5th 2012, so nearly 2011 And that is why it's up to 3 years. We release about every 2 years, but the kernel we have in wheezy was already about 16 months old when wheezy was released. Jessie will freeze in november 2014, so that the kernel will then be about 3 years old. I'm going to assume that the release team is not going to accept new systemd versions from that point on, so systemd should only support a kernel that's 3 years old. Kurt -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131217200907.ga26...@roeckx.be
Bug#727708: systemd jessie - jessie+1 upgrade problems
Kurt Roeckx k...@roeckx.be writes: We release about every 2 years, but the kernel we have in wheezy was already about 16 months old when wheezy was released. Jessie will freeze in november 2014, so that the kernel will then be about 3 years old. I'm going to assume that the release team is not going to accept new systemd versions from that point on, so systemd should only support a kernel that's 3 years old. Right, exactly. It's a real concern, but we should be clear about what our time horizon of concern is. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8761qnql7j@windlord.stanford.edu
Bug#727708: systemd jessie - jessie+1 upgrade problems
Adrian Bunk b...@stusta.de writes: this hits exactly the core of the problem: The minimum supported Linux kernel version in glibc is currently 2.6.16, released in 2006. And I'd trust glibc upstreamt that this requirement won't suddenly be bumped to a quite recent version. Is there any explicit commitment from systemd upstream that releases of systemd releases around 2017 will still contain fallback code to work on kernels from 2013/2014? I'd really like to keep this bug and this discussion focused on what's relevant to Debian as a project, so let's put this in that perspective. The oldest kernel that Debian supports is 2.6.32, released in 2009. But the oldest kernel that we support for upgrades, which is the only point at which systemd backward compatibility matters for Debian's support model, is 3.2.0, released in 2012. The window of backward compatibility that we need is roughly a release cycle plus six months (due to the releases that miss the release window). That's much less than the seven years of the eglibc example. We explicitly don't need to worry about whether systemd in unstable works with the oldstable kernel since we don't support that degree of cross-release compatibility. If we're going to ask systemd upstream questions about this, we should use the actual time period that we care about (about two and a half to three years), not four years and certainly not seven years. But without systemd Debian is free to make the decision when and how to adopt kdbus. If you add a systemd version that required kdbus into the mix, the upgrade becomes messy. That's only true to the extent that we can hold all other packages back, so it's true exactly to the degree that we can choose when and how to adopt kdbus if we standardized on systemd. If we're holding back upstream packages, we can hold back systemd as well. This situation doesn't change, which is Josselin's point. As an additional note: Is there any explicit commitment from systemd upstream that systemd in 2016/2017 will not have a hard dependency on features not in kernels available today? Repeating the same question multiple times in the same mail message is extremely irritating. In the future, when discussing things on the technical committee mailing list, please refrain from doing this. You can assume that everyone reading your message understands which questions you think are important and doesn't require this sort of artificial emphasis. It comes across as badgering. Maybe this was wrongly phrased: of course we should be concerned by compatibility at upgrade time. But using systemd doesn’t cause more compatibility problems than those we already have (e.g. with udev). The exact opposite it true. udev used to be the one package causing huge upgrade headaches back in it's early days when the ABI between udev and the kernel was changing. Later (at least until it was moved into systemd) it was mature and did not cause such problems. systemd is the former udev problems on steroids. I see no evidence to support this contention apart from a bunch of speculation on your part about what *might* happen four years in the future if particular features missed a release window. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87eh5bqqk0@windlord.stanford.edu
Bug#727708: systemd jessie - jessie+1 upgrade problems
Hi Russ, Le mardi 17 décembre 2013 à 12:26 -0800, Russ Allbery a écrit : Is there actually any implementation other than glib2.0 and libdbus that would be affected by a switch to kdbus? This is an interesting question. Josselin, is GNOME (for example) likely to acquire a hard dependency on kdbus through some mechanism? I don't understand the plumbing of this stuff well enough to know where the dependencies could surface. That doesn’t seem very likely to me. In terms of library API, kdbus doesn’t change anything, so there is no need for applications to depend on it. There could be indirect problems, though. * The session bus daemon will probably be started by systemd (using kdbus) when GNOME migrate to systemd user sessions. The old code should still work for some time, but we might have to hold back some packages, and lose some benefits. * Since kdbus is much faster, applications might start to rely on that and lose performance on systems without kdbus. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1387314190.21380.7.camel@tomoe
Bug#727708: systemd jessie - jessie+1 upgrade problems
Adrian == Adrian Bunk b...@stusta.de writes: Adrian Yes, it is speculation that other new features (or even Adrian bugfixes) might appear in the kernel and might become Adrian mandatory in systemd between jessie and jessie+1. Adrian But that is a risk, and it is a risk that is unique to the Adrian systemd option since none of the alternatives is Adrian Linux-only. [2] Adrian My whole point is not about kdbus specifically (which might Adrian even end up in the jessie kernel), but about that (IMHO Adrian substantial) risk. I'm confused, when I hear you say that this risk is unique to the systemd option and not shared by other options. I would understand that statement if we thought we could avoid systemd entirely. It sounds like we may be able to avoid systemd as pid 1 but systemd is very likely to play an important role in the Debian desktop storpy even if we adopt another pid 1. It seems like if systemd starts depending on a new kernel feature then it might well need that feature even when not running as pid 1. So, when evaluating the opportunity costs of this risk in the pid 1 debate it seems like there are two important mitigating circumstances: * The extent to which upstream will provide stability, reducing the risk * The extent to which we cannot avoid the risk even if we choose another pid 1, reducing the portion of the cost of this risk properly in-scope for this bug. I understand some systems may not need systemd if we choose one of the other options. However saying if you installed Gnome you cannot upgrade, seems like a fairly unfortunate statement. At some level, we also need to be community players. Since upgrade stability is important to us, we should advocate for it in open-source projects that we depend on. On the flip side, if enough of the rest of the community after having carefully considered our arguments decides that our desire for stability is too expensive, perhaps we need to reconsider our position. I hope we don't need to do that, but sometimes when enough of the rest of the world disagrees with you, you need to move on. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/tsld2kvw06d@mit.edu
Bug#727708: systemd jessie - jessie+1 upgrade problems
Sam Hartman hartm...@debian.org writes: I'm confused, when I hear you say that this risk is unique to the systemd option and not shared by other options. I would understand that statement if we thought we could avoid systemd entirely. It sounds like we may be able to avoid systemd as pid 1 but systemd is very likely to play an important role in the Debian desktop storpy even if we adopt another pid 1. It seems like if systemd starts depending on a new kernel feature then it might well need that feature even when not running as pid 1. So, when evaluating the opportunity costs of this risk in the pid 1 debate it seems like there are two important mitigating circumstances: * The extent to which upstream will provide stability, reducing the risk * The extent to which we cannot avoid the risk even if we choose another pid 1, reducing the portion of the cost of this risk properly in-scope for this bug. I understand some systems may not need systemd if we choose one of the other options. However saying if you installed Gnome you cannot upgrade, seems like a fairly unfortunate statement. At some level, we also need to be community players. Since upgrade stability is important to us, we should advocate for it in open-source projects that we depend on. On the flip side, if enough of the rest of the community after having carefully considered our arguments decides that our desire for stability is too expensive, perhaps we need to reconsider our position. I hope we don't need to do that, but sometimes when enough of the rest of the world disagrees with you, you need to move on. +1 to all of this. Sam expresses here roughly what I've been trying to express, but much better than I have managed to express it. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vbynniwq@windlord.stanford.edu
Bug#727708: systemd jessie - jessie+1 upgrade problems
Hi Josselin, reading through the systemd position statement [1], I ran into a statement that is either incomplete or incorrect: The upstart position statement [2] states: -- snip -- systemd is hasty. ... While we are committed to having sane upgrade paths and not depend on such kernel features prematurely. -- snip -- The answer in the systemd position statement says: -- snip -- ... Compatibility at upgrade time should not be a concern either, since the real outside interfaces (D-Bus, unit files, Debian configuration files) have always been stable (forward compatible) and will remain so. There will, most probably, be locked-in upgrades with udev from time to time, but it does not have any impact on the ability to upgrade systems. -- snip -- Can you give a pointer to what guarantees systemd upstream makes regarding supporting older kernels? One example: Assume kdbus gets merged into the upstream kernel after the kernel that ships with jessie. Would it be guaranteed that the systemd in jessie+1 will still be able to work with the jessie kernel, or is there even the slightest risk that systemd upstream might at some point make kdbus a mandatory requirement? And with systemd absorbing functionality like module loading I could even imagine nightmare scenarios where additionally the jessie+1 kernel would only work with a jessie+1 systemd. Please clarify whether there is just a pointer to a statement from systemd upstream missing, or whether the statement Compatibility at upgrade time should not be a concern either is incorrect. Thanks in advance Adrian [1] https://wiki.debian.org/Debate/initsystem/systemd [2] https://wiki.debian.org/Debate/initsystem/upstart -- 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-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131216155224.gm30...@bunk.dyndns.info
