On Fri, Jun 10, 2011 at 11:18 PM, Daniel Black
<daniel.subs_at_internode.on.net> wrote:
> As a comparison here's the gentoo build (that I've yet to update) and our
> FreeBSD one:
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/mail-
> filter/opendkim/opendkim-2.2.2.ebuild?view=markup
>
> http://code.bsd64.org/cvsweb/freebsd/ports/mail/opendkim/Makefile?rev=1.7;content-
> type=text%2Fx-cvsweb-markup
Thanks - those are bookmarked and I'll check them out.
> Unlike RPMs these allow user configurable options. Generally I'm in favour of
> enabling features, even experimental features, that are left up to the user to
> enable in configuration files. With RPMs though more features means more
> dependancies which isn't totally a bad thing.
I agree, but I don't want to force install of dependencies with a low
percentage chance of being used by the majority of users. Too many
missing dependencies and they'll just give up.
Looking at
http://www.opendkim.org/INSTALL, I see a number of
compile-time options, but I can't see any in there that are "must
haves" (that aren't already enabled by default). But maybe that's just
because I don't use them. :) Any arguments for any of those that
should be in an RPM for the majority of users?
>> I'm asking for feedback about which of those steps should be modified
>> as I move toward a package that could be made available in repos. Here
>> are my thoughts:
>>
>> 1) add --enable-stats to the ./configure
>>
> yes. This would also require setting up the package and documentation for
> stats.
I'm gonna need guidance here from Murray as to how he'd like to manage
the stats issue, especially since it could raise privacy complaints if
done incorrectly. I'd love to compile it in, and then have some sort
of config option in the default config file like "SubmitStats: no"
that users could change to "yes" (with a comment in the default config
file, of course, explaining what that does).
>> 2) Use the RedHat specific init script from contrib/init/redhat - with
>> hard-coded variables as discussed in a previous thread.
>
> The current init script has a few QA things highlighted by rpmlint so I agree
> here.
I tinkered with the spec file tonight and got rid of all the rpmlint
errors, and now just have warnings - some of which are unavoidable
Which remaining ones are serious enough for me to chase down?
[centos_at_centos32 rpmbuild]$ rpmlint SPECS/opendkim.spec
SPECS/opendkim.spec:67: W: mixed-use-of-spaces-and-tabs (spaces: line
67, tab: line 51)
This one should stay - those are the tabs from the example config file.
[centos_at_centos32 rpmbuild]$ rpmlint RPMS/i386/libopendkim-2.4.0-1.i386.rpm
libopendkim.i386: W: unstripped-binary-or-object /usr/lib/libopendkim.so.4.0.0
libopendkim.i386: W: one-line-command-in-%post /sbin/ldconfig
libopendkim.i386: W: one-line-command-in-%postun /sbin/ldconfig
1 packages and 0 specfiles checked; 0 errors, 3 warnings.
Not sure how serious that first one is, but I couldn't find any way
around the last two, and it doesn't look serious.
[centos_at_centos32 rpmbuild]$ rpmlint RPMS/i386/opendkim-2.4.0-1.i386.rpm
opendkim.i386: W: manpage-not-compressed bz2
/usr/share/man/man8/opendkim-testadsp.8.gz
opendkim.i386: W: manpage-not-compressed bz2 /usr/share/man/man8/opendkim.8.gz
opendkim.i386: W: manpage-not-compressed bz2
/usr/share/man/man8/opendkim-genkey.8.gz
opendkim.i386: W: manpage-not-compressed bz2
/usr/share/man/man5/opendkim.conf.5.gz
opendkim.i386: W: manpage-not-compressed bz2
/usr/share/man/man8/opendkim-testkey.8.gz
opendkim.i386: W: manpage-not-compressed bz2
/usr/share/man/man8/opendkim-genzone.8.gz
opendkim.i386: W: unstripped-binary-or-object /usr/bin/opendkim-genzone
opendkim.i386: W: unstripped-binary-or-object /usr/sbin/opendkim
opendkim.i386: W: unstripped-binary-or-object /usr/bin/opendkim-testkey
opendkim.i386: W: unstripped-binary-or-object /usr/bin/opendkim-testadsp
opendkim.i386: W: spurious-executable-perm
/usr/share/doc/opendkim-2.4.0/convert_keylist.sh
opendkim.i386: W: dangerous-command-in-%post chown
opendkim.i386: W: dangerous-command-in-%preun rm
opendkim.i386: W: missing-lsb-keyword Provides in /etc/rc.d/init.d/opendkim
opendkim.i386: W: missing-lsb-keyword Required-Start in
/etc/rc.d/init.d/opendkim
opendkim.i386: W: missing-lsb-keyword Required-Stop in /etc/rc.d/init.d/opendkim
opendkim.i386: W: missing-lsb-keyword Default-Stop in /etc/rc.d/init.d/opendkim
opendkim.i386: W: missing-lsb-keyword Short-Description in
/etc/rc.d/init.d/opendkim
opendkim.i386: W: service-default-enabled /etc/rc.d/init.d/opendkim
1 packages and 0 specfiles checked; 0 errors, 19 warnings.
Not sure about these ones yet...
>> 3) Really wondering here. Should I make separate config examples for
>> Postfix vs. Sendmail and include them in the docs? Should this conf
>> assume they're using Sendmail? Anything in this example config that
>> doesn't need to be there, or anything that isn't there but should be?
>
> I don't think anything here really assumes postfix or sendmail. I only set to
> inet sockets because getting the postfix permissions is ugly.
>
> The "and putting /etc/opendkim" is a bit redundant with -D specified.
>
>
>> 6) Not sure on this one - I personally use /etc/mail/dkim to store
>> OpenDKIM-related files, with and /etc/mail/dkim/keys/example.com for
>> each domain's keys.
>
> Seems very sendmail like however for real acceptance following the convention
> of the common MTA interacting programs packages in Redhat/Fedora EPEL
> (whatever that works out to be).
Hmm... I think you may have a point here. Hell, Postfix lives in
/etc/postfix so I suppose OpenDKIM can live in /etc/opendkim. Any
other thoughts on this from anyone?
> For me, rpmlint ~/rpmbuild/RPMS/x86_64/ shows a few other things that need
> improving too.
That's what I've been focusing on, too. I'll attach the spec file I've
got so far.
> The opendkim/README should also be installed for the documenation too.
This may be a n00b question, but do you mean in addition to the
current %doc line under %files?
> Keep up the disto push Steve :-)
Thanks - like I said, I'm a complete novice at this, and not a
programmer, so I won't take it personally if anyone points and says
"Dude - you're doing it wrong." But I like learning new stuff, I'm a
believer in OpenDKIM, and I'm appreciative of Murray's efforts, so I
figured I should do what I can to help. :)
SteveJ
Received on Mon Jun 13 2011 - 04:27:02 PST