Hey Steve,
On Saturday 26 March 2011 10:30:18 Steve Jenkins wrote:
> On Fri, Mar 25, 2011 at 10:29 AM, Murray S. Kucherawy <msk_at_cloudmark.com> wrote:
> > There's an RPM spec file in contrib/spec if you want to use that as a
> > starting point. We can apply patches to it or clone it for different
> > systems if that's appropriate.
>
> Thanks, Murray and Andreas. I peeked at the spec file for dkim-milter,
and you saw the spec file in the contrib directory too? I wondered why your blog refers to
a manual compile rather than using this spec but I digress.
> I guess my first question would be... what options (if any) should be
> compiled in when the RPM is installed?
To go off what other distos are packaging:
http://patch-tracker.debian.org/patch/debianonly/view/opendkim/2.0.1+dfsg-1 - see the
debian/rules section
FreeBSD:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/mail/opendkim/Makefile?rev=1.5;content-
type=text%2Fx-cvsweb-markup
Gentoo:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/mail-
filter/opendkim/opendkim-2.2.2.ebuild?view=markup
(yes I didn't get to 2.3.0 but I will do 2.3.1)
Note gentoo and freebsd support options that allow for a bit more flexability. They have
default options (gentoos is evident by the +db).
> Stats?
It does pull in the berk/oracle/sleepycat dependancy but i think thats a good idea.
> Anything else?
I'll generally enable any experimental option that doesn't alter the logic flow internally.
Ones that add configuration options are good because they give the user choice.
> Should a
> simple /etc/opendkim.conf file be autocreated?
I added the simple samples in the opendkim directory for this purpose. Something really
simple to get users going.
> Should a sample set of keys,
yes.
> SigningTable,
> trusted-hosts, and KeyFile be generated
bit too complicated. Let the user documentation guide this if that what the user requires.
> ? Should
> the appropriate sendmail and/or postfix config files be modified?
There is probably packaging rules against this type of thing. The documentation should
guide this part of the install.
> I want to make this RPM applicabe for the most common case - which is
> probably a single server, signing for every user on a single domain,
> verifying incoming mail (but maybe not really doing anything about it
> other than logging for now?).
sounds like a good goal.
> I don't want how I personally use it to over-influence how the
> majority of users will use it.
If i wanted to influence uses in any small way I'd try to get stats reporting easier to get
going.
A very busy friend of mine just became a fedora maintainer. I'm happy to test out spec
files on my work (non server) machine from a packaging point of view and work with him to
try to get distribution inclusion.
Received on Sat Mar 26 2011 - 00:04:16 PST