http://bugzilla.spamassassin.org/show_bug.cgi?id=3668
Summary: [RFC] Some last minute path/file thoughts
Product: Spamassassin
Version: SVN Trunk (Latest Devel Version)
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P1
Component: Libraries
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
While I looked through our codebase and the installed SA on my box, I noticed
the following path and/or filenames issues. Sorry abou the late time, but most
of this stuff came to my mind last weekend.
-> The old question about /etc/mail/spamassassin vs. /etc/spamassassin: Do we
want to change this?
While I am working on SA, I regularly (as in: once per half year ;) hear
complains about that path name. The best argument against it was,
that /etc/mail is historically used by sendmail. Another good one is that this
path is simply too long, the /mail part doesn't add any value. I think some
distros like debian already changed this.
The argument against it is that it was always this way and if we switch poeple
won't have their .cfs loaded anymore (OTOH are they most probably full of
outdated options anyway).
If we ever want to change it, we should do it for 3.0.
-> /etc/mail/spamassassin/init.pre: What the heck is this? Ok, the inline
docu explains it but I couldn't find any other description of this file. I
just noticed this file after I accidently removed my /etc/mail/spamassassin,
copied back a backup of my local.cf and after a few days noticed that a bunch
of plugins doesn't work anymore.
I don't like the name at all; our config files are called *.cf, for me
everything else is stuff I don't have to fiddle with like the Bayes DB.
-> ~/.spamassassin/user_prefs: What do you think about renaming this to
~/.spamassassin/user.cf or something like that? The reason is more or less the
same as above, additionally are most of our database files (which the user
shouldn't manipulate directly) in the form foo_bar. Of course could we make
the codebase still read the user_prefs file for backwards compatibility, just
give it a new "official" name.
-> /usr/share/spamassassin/*: Currently we have the policy that you must not
put anything into /usr/share because it will most probably get overridden on
the next update. But now that we support plugins, I think their data belongs
into that directory, too. What do you think about moving all our stuff
into /usr/share/spamassassin/core/, allowing people to create their directory
at the level above?
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
