Adrian Bunk <[email protected]> writes: > On Sat, Jan 18, 2014 at 08:49:48PM -0800, Russ Allbery wrote: >> Adrian Bunk <[email protected]> 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 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. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
