Bugzilla Bug 195690

--- EHNANCEMENT SUGGESTION (SO NO "EMERGE --INFO" INCLUDED/NEEDED) ---

So I was wondering why I got cron mails telling me that my aide-database
doesn't exist why still getting the regular mails from aide -C's output as it
should be. 

The annoying thing was, that these irregular cron-mails were bounced messages
from localhost.de (and not localhost) and I still couldn't get what was wrong
until I found the cron-script installed by Aide. 

This script uses /bin/mail for dispatching the messages and somehow /bin/mail
expands "localhost" to "localhost.de" while using postfix directly does it
right.

Anyways, my suggestion would be to make the installation of the cron-script
optional, maybe via a useflag.

Reproducible: Always

Steps to Reproduce:
n/a

Actual Results:  
n/a

Expected Results:  
n/a

n/a

A use flag for installing one plaintext file plain sucks, we just recently got
rid of USE=udev which was doing the same pointless thing. 

Why don't you configure your local mail correctly, use INSTALL_MASK or delete
the cronscript if you don't want it?

(In reply to comment #1)
> Why don't you configure your local mail correctly
It is configured correctly. Unfortunately mailx seems to have the idea that
mail-addresses in the form of user@host are incorrect and appends some tld to
the host-part. I haven't found the origin for this expanding behaviour yet (I
even straced it). As I wrote: Postfix, ping and everything else I could use
resolve "localhost" correctly to 127.0.0.1 -- only mailx fails.

>, use INSTALL_MASK
Never heard of this one, I will have a look at it.

> or delete the cronscript if you don't want it?
because portage/etc-update would put it there, again leading me to the same
problem once aide gets upgraded.

(In reply to comment #2)
> (In reply to comment #1)
> It is configured correctly. Unfortunately mailx seems to have the idea that
> mail-addresses in the form of user@host are incorrect and appends some tld to
> the host-part.

File a bug about mailx. Meanwhile user@host. (the trailing dot is important)
should work-around this broken behaviour.

INSTALL_MASK solved this problem. I am blocking the script now.

> File a bug about mailx. Meanwhile user@host. (the trailing dot is important)
> should work-around this broken behaviour.
Why should I configure something (i.e. the Aide-Cronjob) I do not want to use
at all? ;) 

I don't care about mailx since I do not use it. Instead, aide should probably
utilize a sane and more forgiving MUA instead of mailx. The well known
sendmail-symlink-wrapper magic could help, although I have to admit that I do
not know how the various MTAs handle it.

The ebuild shouldn't be installing a script for cron to execute at all.  It is
fine to provide an example script and put it somewhere with the documentation
or something where someone can copy it into place if they want, but it is
troubling to have a daily cron job just show up when you install aide.  It is
also troubling to have to install a run-time dependency (which pulls in it's
own dependencies) just for a script that really shouldn't be installed by
default.

I vote for installing the script into /usr/share/doc/aide-0.13.1/example or
something, maybe put in an elog saying that it is there, and remove
virtual/mailx from RDEPEND.

I would agree that installation of a default script is not really appropriate
in this case. Filesystem integrity checking is complicated enough that a
one-size-fits-all script is probably not going to do the job, particularly at
large deployments. It is rather nonintuitive to install this utility and
suddenly discover processes running out of cron and extraneous mail showing up,
 particularly if you were using an earlier version and already had your own
infrastructure in place.

I think providing an example script would be a much better approach.

Thanks...

Removed /etc/cron.daily/aide in 0.13.1-r1

It looks like you forgot to remove virtual/mailx from RDEPEND.