On Fri, Mar 25, 2011 at 5:05 PM, Daniel Black
<daniel.subs_at_internode.on.net> wrote:
> 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.
Um... because compiling is AWESOME! ;)
I guess I see RPMs = giving a fish vs. compiling = teaching to fish,
and I simply felt like teaching to fish in that blog post. But, as we
all know, there are always going to be more people just wanting
fish... and since I'm a big fan of OpenDKIM, I'd really like to see it
as easy to install on the RH-flavor distros as "yum install opendkim,"
with the goal of having it available in commonly-used repos.
> 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
Thanks! I'm all over those.
> (yes I didn't get to 2.3.0 but I will do 2.3.1)
No hate here, bro. :)
> 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.
I have noticed my cat does sleep a lot. LOL. I have no idea what this
means, but I'll do some research to make sure I'm briefed before
proceeding.
>> 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.
Great suggestion.
>> 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.
Concur.
>> Should a sample set of keys,
> yes.
Also concur.
>> SigningTable,
>> trusted-hosts, and KeyFile be generated
> bit too complicated. Let the user documentation guide this if that what the user requires.
OK, maybe have their directives included in the default conf file but
commented out?
>> ? 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.
True. I don't want Wietse mad at me. :)
>> 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.
Cool. That's the direction I'll head.
>> 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.
I was really leaning that way. I think the pkg docs should make a
convincing case for sharing stats with Murray's mothership. I'd really
like to automate the stats setup as much as possible so that Murray
doesn't get overloaded with "add me to the stats lists," tho.
> 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.
That sounds great. Thanks, Daniel. Like I said, this is new territory
for me, but I've always found that doing someone brand new is the best
way to learn. Thanks also to many of you in advance, because I know
I'm gonna be posting some n00b questions along the way...
SteveJ
Received on Sat Mar 26 2011 - 04:42:46 PST