Re: Anyone packaging for RHEL/CentOS/Fedora?

From: Daniel Black <>
Date: Sat, 26 Mar 2011 11:05:37 +1100

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 <> 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: - see the
debian/rules section



(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,

> 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

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

This archive was generated by hypermail 2.3.0 : Mon Oct 29 2012 - 23:33:09 PST