Sjoerd Simons <sjo...@debian.org> writes: > Essentially this boils down to whether the logind interfaces will be > available when using sysvinit. Most of the other interfaces (at least > for current gnome as in experimental) would cause some functionality to > either be missing or not work, but wouldn't yield a completely unusable > system.
Thanks for that. That's one of the key pieces of information that I was wondering about, and I was just told I should probably talk to you since you'd know. :) > Not having the logind interface is a lot harder to cope with and > something that will not only impact Gnome. So essentially the most > likely impact of using sysvinit _without_ a provider of the logind > interface would be a non-usable Gnome desktop (and potentially even GDM > to be unusable) on Jessie systems. If we go with systemd, I think we have three options: 1. Allow packages that require logind to depend on systemd and require that it be used as the init system. This is certainly the simplest for packaging applications that want to depend on logind, as well as for the systemd maintainers. However, it means we lose the ability for users of at least those packages to be able to fall back on sysvinit if something goes wrong with systemd on their systems. In the past, we've tried pretty hard to provide that capability when making a disruptive change of this kind. 2. Package logind separately from systemd, get it working with sysvinit. The problems with doing this, as I understand it, is that we'd not be able to upgrade such a separately-packaged logind beyond 204 for jessie. I'm not sure how much impact that would have. Also, it sounded to me like we would need to figure out who was going to do that work and maintain that package, including in the stable release. If the current systemd maintainers are not interested in doing this, we absolutely shouldn't try to force them to do so. Someone else would need to step forward to do this and figure out the right package relationships. (Also, it would be good to maintain this separately so that the systemd maintainers could move forward with newer versions of systemd, including the logind built from its source.) 3. Get GNOME working at some level without logind. I think it would be entirely acceptable for there to be some loss of functionality when GNOME is started in this way, such as no user switching and some configuration and control panels that rely on logind functionality not working. But it would need to at least start and be basically functional for this to be a meaningful option. None of these options are very appealing, but I think we have to pick one of them. I'm not seeing other options at the moment. I think option 3 would be the most appealing for the project as a whole, but I realize that's also the option that puts the most burden on GNOME maintainers. The only upside I can offer for that is that this would be in the context of moving forward with systemd and would be a one-release issue. Post jessie, you'd be able to move forward with a standard integration. It's worth noting that option 3 is also what would be required if we wanted to support GNOME on kFreeBSD. I'm not sure if anyone is working on that port or sufficiently interested in it to try to make it work, but there may be some additional resources there. Do you think there's a way that we could make option 3 work that the GNOME maintainers would be comfortable with? The systemd maintainers should definitely feel free to tell me if I'm misunderstanding their feelings on option 2. Do you think I should ask more generally on debian-devel if there are any other maintainers in Debian that anticipate any problem with either requiring sysvinit be supported as PID 1 for jessie, or with logind being an optional component for jessie? If we go with upstart as the default, obviously the situation is much different, possibly including multiple different maintenance teams, and would require packaging a broken-up version of systemd and building a maintenance team around that. It's basically option 2 with a bunch of added disruption. There are enough variables involved in that situation that I hesitate to guess what it would look like. -- 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
