The ubuntu meta packages indicate which pieces of software are part of the supported Ubuntu system, we don't support syslog-ng (it's in universe) and by replacing syslogd with it you are choosing not to have a supported system.

I agree with the logic that syslog-ng is not a supported piece of software, and thus using it instead of sysklogd makes ones system not supported.

However, the current way the dependencies are specified removes all of whatever benefits the 'ubuntu-minimal' package has to anyone who knows syslog-ng well enough to use it (as anyone who knows it that well would certainly use it instead of sysklogd, given a choice of just those two).

Also note that sysklogd and syslog-ng do not actually conflict with each other. In general, it's not a good idea to have both running on the same log data at the same time. However, I have seen a log server that used syslogd for local logging, and syslog-ng for receiving logs from other systems. It worked just fine. (Note: they were not writing to the same log files. Having them write to the same files would have defeated some of the point of the (admittedly, quite silly) purpose. Said purpose was, incidentally, lack of trust for syslog-ng. The company in question changed to running just syslog-ng after about 6 months, having seen how vastly superior syslog-ng is.)

Finally, this is simply a matter of fixing dependencies. It should be a really quick thing to do. Instead, we've had at least four bugs submitted, at least one brainstorm idea, and at least two years have passed since the first bug was filed. This should have taken less than two weeks, including QA and review.

We don't intend to change the metapackage - doing so would actually make it harder to switch people over to a single different standard logging daemon, because the dependencies would still permit sysklogd so we'd end up supporting two logging daemons indefinitely. This is exactly the kind of reason we specify individual implementations in the metapackages rather than using virtual packages. If you don't want to follow our recommendations then you're quite welcome to remove the metapackages. I realise people are unhappy with this, but I don't think we can please everyone here.

I don't intend to close this bug as Won't Fix, though; firstly, it would probably just get re-filed, and secondly, maybe in the future we will come up with a better way to deal with this kind of thing. At the moment, though, using alternative dependencies in the metapackages is (in our best judgement) not that better way.

I would personally suggest that sysklogd has sufficiently limited functionality that one could justify removing it from the supported system-log-daemon providers entirely. Doing that would cause people who were using it due to it being the default to automatically switch to the new default of rsyslog.

For what it's worth, I still object to considering system-log-daemon to be a conflict for these programs. Doing that makes investigating another one of these packages needlessly more difficult.

3 years later (in this thread, and over 5 from the others) and this 'political battle' is still going on. Please resolve these dependancies. This has nothing to do with support, it is purely a dependancy linkage issue of the ubuntu-minimal package. This is a major pain when trying to run secuirty servers that need more detailed log parsing from other syslog packages and doing the normal updates which this requires custom scripting now to un-screw each system after updates.

I agree with @stevecs, this is rather annoying to hold the ubuntu-minimal package, then recompile my own with a one line fix in it's depends after each meta package update. I'm disappointed by politics being brought into this; isn't FOSS supposed to encourage choice?