Re: OpenDKIM RPM Progress

On Sun, Jun 12, 2011 at 9:26 PM, Steve Jenkins <stevejenkins_at_gmail.com> wrote:
> 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
>

Sorry - forgot to attach my current spec file for those who might be interested.