Sjoerd Simons wrote: > * e366cac Rework the semantics of restart job deadlock avoidance during early > boot and shutdown. > > The main patch here was sent to the systemd list, from the discussion it > seems upstream doesn't like that approach. I don't think this is an area > where we should diverge, so probably should be dropped
The current discussion looks like upstream is somewhat clueless about this issue; IMO the patch shouldn't be permanently dropped with a "upstream disagrees" resolution while upstream's last posted rationale was not even factually correct (the last post was wrong at least about what the current behavior actually is and about the backwards compatibility situation). It should be discussed further until any decisions are based on correct facts. I don't know how long Lennart's mail queue is and whether he intends to reply to the existing discussion or if it should be brought up again. Note that this change *replaces* a previous Debian patch. The previous patch is a semantically incorrect hack and certainly will not be accepted upstream. Thus any "divergence from upstream" argument is IMO wrong while the worse patch is still there. Bug #759098 was already reported about the reload-while-inactive part that upstream changed after 208, but which is backported to current Debian 208. This patch also restores the <= 208 semantics. (Note that the rationale given in the upstream commit for that change was dubious/wrong, and Lennart was not aware of this change history in the discussion about this patch, so the situation is quite unclear). > * cc46ad0 Add breaks on old syslog providers, they interact badly with the > journal. > > Adds breaks on syslog providers not supporting systemd, some > unversioned. Probably not something to grab (especially unversioned > breaks are harmful). But probably worth considering what the strategy is > for syslog providers that don't support journald for jessie? Do those break the syslog socket and prevent things from being logged to the journal? If so, that seems bad enough that there should be some mechanism to make sure the situation does not happen, at least not without a conscious and explicit admin decision. _______________________________________________ Pkg-systemd-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
