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-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
