Marc Haber <mh+debian-packa...@zugschlus.de> wrote:
And your patch doesn't completely kill the noise feature, which is
something I'd hate to lose. On the other hand, the new code has like
six temporary files (I actually stopped counting at some point), and
is rather complex for the daily cron job.
Currently I'm merging the filter and the de-noise part, so that
the de-noised output is also really filtered.
I'll try to reduce the number of needed temporary files.
Additionally I'm developing another feature to compactify the mail
output. Meaning the "detailed changes" part is outsourced to the log
file and the "changed files" part looks like
f..s.....mc..C..: /var/log/ConsoleKit/history
instead of
changed: /var/log/ConsoleKit/history
Every letter represents a changed attribute (in this case: a file (f)
with changed size (s), Mtime (m), Ctime (c) and one or more Checksums (C)).
That means that in mail you only see what attributes have changed but
not how.
I am not yet convinced whether this is desireable, and I'd probably
prefer the method of re-running aide after doing system updates.
The problem with completely re-running aide after system update is that
either you have to review thousands of changed files or you miss
changes not related to system update. In my mind the best solution for
that would be to update only a list of files in aide database. Is that
possible?
Is it really necessary to have a temp file orgy like this, or is this
maybe the point where the shell script should be rewritten in a "real"
programming language?
As said above, I'll reduce the number of temporary files.
What "real programming language" would you prefer?
regards
Hannes
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
