Add :syslog to included_applications

[aaronjensen]

Without this, when running an exrm release on the exrm 1.0.4, when exsyslog attempts to start syslog, it will already be started and crash.

@bitwalker does this seem right? Is there something else wrong? This was not the case on 1.0.0-rc7, it was introduced somewhere after that.

[bitwalker]

@aaronjensen I would guess this is due to the foreground task not running the release in embedded mode like it was supposed to. In other words, the behaviour pre-1.0.4 was not intended. What you are describing here is the expected result: if you need to control the start/stop lifecycle of an application or set of applications, then all of those applications need to be in :included_applications rather than :applications. The former is used when you will be handling starting and stopping them, the latter when you want the runtime to handle it for you.

[aaronjensen]

Ok, thanks, though should this package add syslog to included_applications itself rather than asking its consumers to add it?

[bitwalker]

Given the role of exsyslog, I'd say yes, it should have it in included_applications, since it's exsyslog, not the consumer which will be responsible for the syslog lifecycle. It does mean that consumers can't add syslog to included_applications themselves, as only one application in a release can "include" some other application, so it's worth documenting that, but I would guess users of exsyslog don't really need to work with syslog directly, so it may not be an issue.

[aaronjensen]

Superseded by #6