Remaining 214 patches from Jono

[Sjoerd Simons]

On Mon, 2014-08-25 at 04:05 +0300, Uoti Urpala wrote:
> 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.

Yeah, i don't like the previous hack either for the same reason. I am
very very concerned about us changing behaviour in places like this from
upstream, not because upstream can't be wrong, but because it's like
people will expect the upstream behaviour in e.g. scripts they write.

So, i personally, would rather see this hashed out with upstream first
before making more changes.

> 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).

Yeah it's exactly these types of issues i'm worried about. If we just
change it in Debian we'll still get these types of issues when using
scripts initially written for other distributions.

> > * 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.

I must say i haven't tested the behaviour of the various daemons with
respect to new (or old) systemd.. Starting with 214 /dev/log is a
symlink to /run, so the failure case might have changed. However both
the situations where either the journal or the syslog daemon don't get
the message they expect are bad. Hence my question about the strategy
around this, because apart from say Breaks it should also be clear to
maintainers of other syslog implementations what is expected from them. 

There are actuall two things going on with the patchs, first it's adding
breaks on older versions of some syslog provides from before they had
journald support. Which is probably sensible, but it's not a 214
specific thing so i wonder why that wasn't done before (not necessary?)

The second is that it has unversioned breaks on a bunch of syslog
packages, which is always nasty as that means that when those packages
do get fixed a new sourceful upload of systemd is required to
remove/update the breaks.



-- 
Sjoerd Simons <sjoerd at luon.net>