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