Re: loosing dependencies: Depends: on logrotate
>>>>> Don Armstrong <don@debian.org> writes:
>> Exactly. If any of the old, rather inflexible syslog implementations
>> depended on logrotate, I would say that would be perfectly fine. But
>> for applications (even if they write their logs themselves like
>> apache or samba usually do), I would only expect a simple
>> Recommends. On my servers, I'm forced to have logrotate installed
>> due to applications like samba, even though I immediately disable
>> logrotate after installation and use my own rotation scripts (for
>> those applications not using syslog - syslog-ng in this case)
>> instead.
> You need to have some kind of log rotation in place, so a depends[0]
> is perfectly appropriate, since the only type of log rotation that we
> actually distribute is logrotate.[1] (I mean, without *some* kind of
> log rotation, you're going to run out of disk space eventually, which
> seems to me to be a pretty important bit of functionality.)
To this end Priority: important seems to be enough.
It's up to policy to specify which log rotation package (or
rather interface) is to be supported by all of the packages (and
thus by the system.) But it should be left to the user to
decide which package to actually use.
> Since samba even distributes an appropriate logrotate config file, it
> obviously depends on it.
In much the same way that debian-policy package depends on
www-browser?
To my mind, /etc/logrotate.d/ file is completely an option.
Whether the user will use it or not is to be left to his or her
own discretion.
> Finally, it's not like you can't indicate that you're dealing with
> logrotation by yourself by using an equivs package to work around the
> dependency.
Indeed. Though I don't think that such a workaround should be
required.
> Don Armstrong
> 0: And actually, it's not clear to me why syslog-ng doens't depend
> on logrotate.
> 1: TTBOMK, of course; if there are others, then there possibly should
> be a metapackage for them.
This would require the /etc/logrotate.d/ files parsing to be
implemented by the packages providing that metapackage. In much
the same way that the `Provides: x-terminal-emulator' packages
are expected to provide an `x-terminal-emulator' alternative.
[...]
Reply to: