Depends: logrotate (forever and ever and ever)
>>>>> Andrei Popescu <andreimpopescu@gmail.com> writes:
>>>>> On Vi, 16 sep 11, 00:48:25, Ivan Shmakov wrote:
[Cc: debian-devel@, for this discussion fits there better.]
>> I wonder if there should be a separate mailing list to Cc: such bug
>> reports. (debian-dependency-inquisitors@, perhaps?)
> I don't think dependencies need any special handling compared to
> other bug reports. In cases where you don't agree with the resolution
> you can discuss the issue - together with the maintainer - on
> debian-devel.
Perhaps.
>> I seem to remember that there was a longstanding issue with Depends:
>> logrotate. Of course, no package should ever be “rendered unusable”
>> (which, AIUI, is the very essense of Depends:) should logrotate not
>> be installed!
To quote the policy:
--cut: http://www.debian.org/doc/debian-policy/ch-relationships.html --
The Depends field should be used if the depended-on package is
required for the depending package to provide a significant amount
of functionality.
--cut: http://www.debian.org/doc/debian-policy/ch-relationships.html --
Cf.:
--cut: http://www.debian.org/doc/debian-policy/ch-relationships.html --
Recommends
This declares a strong, but not absolute, dependency.
The Recommends field should list packages that would be found
together with this one in all but unusual installations.
--cut: http://www.debian.org/doc/debian-policy/ch-relationships.html --
>> Yet, there seem to be something like 45 packages that Depends: on it
>> as per Debian Wheezy.
> Could you provide concrete examples?
Sure.
$ apt-cache show $(apt-cache rdepends logrotate | sed -e '/^ /!d; s///') \
| grep-dctrl -s Package -F Depends --regex --pattern=logrotate \
| LC_ALL=C sort -u \
| sed -e '/^Package: /!d; s///' | fmt -w72
aolserver4-daemon argus-server atop battery-stats boa cherokee
clamav-base clamav-freshclam clamav-milter deejayd deejayd-webui
interchange ippl knockd leafnode libvirt-bin lusca mailman mgetty
muddleftpd net-acct ninja prayer privoxy pyca pygopherd quagga
rabbitmq-server rsnapshot sipwitch sks slbackup snort snort-mysql
snort-pgsql squid squid3 tinyproxy twatch uucp
$
> I assume packages not logging to syslog do need some rotation of
> their logs, otherwise they could render systems unusable by filling
> up the drive.
The use of logrotate doesn't prevent it; and the lack of such
use doesn't force it, either.
In particular, when the package is installed into a chroot (say,
for testing), the Cron daemon is typically not run from there.
Thus, chroot'ed logrotate won't ever be run, and won't have any
effect on the free filesystem space.
Also, certain server packages may be run both privileged (as a
system service) and unprivileged (for just the invoking user.)
(Think of, e. g., Rsync, but INN also can be configured in such
a way.) There, logrotate is ineffective just as well, as the
packaged configuration files certainly won't reference the
filenames used by the particular user.
Note that there's a reasonable amount of packages which either
Recommends: or Suggest: logrotate instead:
$ apt-cache show $(apt-cache rdepends logrotate | sed -e '/^ /!d; s///') \
| grep-dctrl -s Package --not -F Depends --regex --pattern=logrotate \
| LC_ALL=C sort -u \
| sed -e '/^Package: /!d; s///' | fmt -w72
atftpd bdii cacti cricket cron ctdb distributed-net dsyslog heartbeat
heimdal-kdc horde3 kdm ldirectord liquidsoap masqmail mini-buildd-bld
mini-buildd-rep pawserv rsyslog samba selinux-policy-default
selinux-policy-mls sendmail-base sugarplum super sympa syslog-ng
thttpd tor vsftpd wu-ftpd wwwoffle xinetd xtel xtide zabbix-agent
zabbix-proxy-mysql zabbix-proxy-pgsql zabbix-proxy-sqlite3
zabbix-server-mysql zabbix-server-pgsql
$
Moreover, there's at least the dpkg package which, while
providing logrotate configuration files, doesn't mention
logrotate among its dependencies at all.
It's therefore my long-standing opinion that the dependency on
logrotate should be downgraded to Recommends:, unless, of
course, postinst or prerm do actually use anything provided by
the logrotate package (which seems to me unlikely.)
--
FSF associate member #7257
Reply to: