Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> Russ Allbery writes ("Bug#727708: loose ends for init system decision"):>> These requirements, on the other hand, I find completely baffling. >> This approach seems completely contrary to Debian best practices. Our >> standard practice with all packages is to fully enable all available >> features that make sense on Debian and don't pose some concrete risk. > The case in point is a little different. It's one thing to say that > mail daemons should come with ldap support enabled, or whatever (and > even then we sometimes have two versions e.g. "heavy" and "light"). I'm aware of only one case of that in the archive. It's certainly not what we normally do. > For me it's a different proposition to suppose that _every_ daemon > should bring in these kind of dependencies. It's only going to be *every* daemon if we select systemd as the default init system, in which case we should be doing this in many daemons for either socket activation or for readiness notification as part of a proper systemd integration. If we do not select systemd as the default init system, the only maintainers doing this will be those who want their packages to work well with systemd or whose daemons are of particular interest to people who want to run systemd as a non-default init system. In which case, what's the harm? It's going to be very difficult to even notice this dependency is there. I think the position you're taking here is directly contrary to Debian's position of deference and reasonable accomodation to things that people want to work on. > This is particularly the case for build-dependencies on an avowedly and > intentionally non-portable program. Of course this can be made > conditional, but this is IMO too fiddly. Adding [linux-any] to the Build-Depends line is not too fiddly, and if the goal is to enable optional upstream support for systemd, that will be sufficient. Besides, in general, it's up to the packager to decide what is or is not too fiddly in how they want to package software. Obviously, we should not add an unconditional build dependency for a library that isn't available on some of our ports to software that can work on those ports. But I think that's obvious. I'm happy to have us say that explicitly if if helps. >>> We should recommend: >>> - daemon authors and Debian maintainers should prefer command-line >>> options to environment variables >> I disagree with including this in a statement. I think it's outside >> the scope of what we were asked to resolve, and I don't think it's the >> place of the TC to offer this sort of general advise to upstreams. > It is very likely that Debian contributors will be implementing native > support for whatever readiness protocol, in the upstream parts of the > codebase. It is IMO appropriate for those contributors to get advice on > how to do this. Policy already gives advice on this kind of thing. > Given the context, and the fact that this advice is going to be read by > a lot of people as part of a big enhancement project, I think it's > appropriate for the TC to answer this question. If you feel like Policy should give advice on this, you can bring it up in the context of Policy. I don't think the exact mechanism of integration is important enough for the TC to explicitly favor a particular mechanism, and different upstreams may have different approaches. I'm not seeing the important gain to Debian here in trying to standardize exactly how one tells a daemon to use socket activation or readiness notification. I also, for what it's worth, directly disagree with this advice with respect to systemd because I think compatibility with how systemd is used elsewhere is more important than any marginal gain from using a configuration method that's not inherited by subprocesses by default, particularly given that the standard systemd APIs include environment sanitizing. But I also don't see any point in arguing about it here, since I don't think this dispute is ripe (in the legal sense). If you do bring it up in the context of Policy and we can't resolve the debate there, it can get appealed to the TC and we can decide it here separately, but I think this is all premature, given that the whole point becomes basically moot if we don't pick systemd anyway. If you're worried about programs configured with environment variables in the archive, you've got quite a lot of work to do, starting with nearly every Perl program in existence. >> If we're going to offer specific advice, we should limit it to the >> specific integrations that we're asked to consider. But I think we >> should be mindful of the restriction on the TC not doing design work >> and let Policy for packaging support of upstart and/or systemd be >> hashed out through the regular Policy process. > Are you proposing then that the TC should decide the default init > system, but asmk people NOT to start converting packages until the > policy questions are settled ? Sure. I think that's what's going to happen anyway. Again, it's not the place of the TC (explicitly, per the constitution) to do design. Once we decide on a direction, we should let the rest of the project work out the details using our normal procedures. We have a fair bit of time left before the jessie release, and I expect integration policy to be fairly well-resolved by the end of February using our normal process. And even if it's not, given that we need to support sysvinit for jessie anyway, I expect most packages will not be in a rush to convert. -- 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
