> -----Original Message-----
> From: Steve Jenkins [mailto:stevejenkins_at_gmail.com]
> Sent: Sunday, June 05, 2011 9:13 AM
> To: Murray S. Kucherawy
> Cc: opendkim-dev_at_lists.opendkim.org
> Subject: Re: 2.4.0.Beta1 available
>
> > The new script uses values provided by ./configure, i.e., it's auto-
> > generated based on autoconf options. The source form can be found in
> > contrib/init/redhat/opendkim.in where it uses the --prefix value to
> > build the path.
> >
> > I had --sysconfdir in there too, but that produces something like
> > ${prefix}/etc, and ${prefix} isn't defined so that didn't work. So
> > maybe the simplest solution is to import ${prefix} first so that does
> > work, and then your script will be generated to match your
> > configuration. So if you do:
> >
> > ./configure --sysconfdir=/etc --prefix=/usr/local
> >
> > ...then you should get binaries in /usr/local/sbin and opendkim.conf
> > in /etc.
> >
> > I'll send you a replacement Makefile.in offlist to try.
>
> I'm actually testing with Beta 6, but wanted to reply to this thread
> for context. I realize that Daniel prefers to build RPMs, but I'd
> still like to think there's a straightforward method to be able to do
> "configure, make, make install" and then copy the RedHat init script
> to the appropriate directory and it just WORKS. However, even with the
> configure options you mentioned above, Murray, if I copy the default
> init script to /etc/init.d/ and try to start OpenDKIM I get this
> error:
>
> Jun 3 15:44:36 tapper opendkim[25590]: can't write pid to
> /usr/local/var/run/opendkim/opendkim.pid: No such file or directory
> Jun 3 15:44:36 tapper opendkim[25591]: OpenDKIM Filter v2.4.0
> starting (args: -x /etc/opendkim.conf -P
> /usr/local/var/run/opendkim/opendkim.pid)
>
> The only way to get things working properly again is to use my default
> init script (which is the same as the last version I submitted).
>
> Again, I'm way more script-kiddie than programmer, so maybe I'm
> missing something. When ./configure is run with those options, does
> that affect the startup script? Or does it affect the location that
> the binaries get copied to? Why was the prefix support stuff added in
> the first place? Is it because the "roll your own RPM and install it"
> method sticks the files in different locations than the "configure,
> make, make install" method?
When you run "./configure" with those options, the file contrib/init/redhat/opendkim.in is run through some post-processing (based on those options) and that generates contrib/init/redhat/opendkim. This also applies to each Makefile.in (just about every directory has one), which produces the various Makefiles, which in turn control where things get installed. Supposedly this should work fine because the binaries and the scripts will thus all agree, since these paths then all come from the same source.
The RPM spec file in contrib/spec is also generated this way, so whatever your path prefixes provided to "./configure" pretty much permeate everything. I believe the intent was to allow the RPM to be built for various systems based on these options; Daniel will have to clarify if I have that wrong.
It looks like you need one more thing to replace /usr/local/var with /var in your generated files. That's "--localstatedir=/var", I believe.
I think (so far) that this is the right way to go because the preferred defaults for each of these vary from one OS to the next, including on things that aren't Linux (FreeBSD, for example).
To skip having to do all this each time, and just have "./configure" do all this automatically, you're likely to want an autoconf site file. It looks like you could set an environment variable to do this too if you prefer. More info here:
http://www.gnu.org/s/hello/manual/autoconf/Site-Defaults.html
-MSK
Received on Mon Jun 06 2011 - 05:11:42 PST