Bugzilla – Bug 213
sendmail path in torque.spec influenced by _prefix
Last modified: 2012-08-13 13:12:48 MDT
You need to log in before you can comment on or make changes to this bug.
When using rpmbuild, the torque.spec file supplies its own --with-sendmail=%{sendmail_path} parameter to configure (instead of letting configure autodetect it).It expands to %{!?sendmail_path:%global sendmail_path %{_sbindir}/sendmail}. So it's either an user-supplied path, or _sbindir (which is already an incorrect assumption). However, this is referring to the build's sbindir, not the system's. We use --define "_prefix /opt/torque" to change the install path, and apparently _prefix influences _sbindir, because all Makefiles get SENDMAIL_CMD = /opt/torque/sbin/sendmail which is a nonexistent path. My suggestion is to make the entire --with-sendmail configure parameter optional, only instantiate it when the user provides a specific path, and leave it up to the default configure behavior otherwise.
The spec file behavior is as expected. To override the default assumptions, simply pass the following parameters to rpmbuild: --define 'sendmail_path /path/to/your/sendmail'
So you consider torque trying to run /var/spool/torque/sbin/sendmail to be normal? The workaround you posted does work, but I'd prefer to use the defaults... and the default is flawed - it's hardcoded to SBIN/sendmail, however in our SL6 install it's /usr/lib/sendmail which symlinks to mta-postfix. The default configure script locates this correctly, but torque.spec inserts its own value and breaks it.
(In reply to comment #2) > So you consider torque trying to run /var/spool/torque/sbin/sendmail to be > normal? Your attempt to be snidely witty is noted and appreciated, but --prefix/%{_prefix} and --with-server-home/%{torque_home} are entirely separate and very different settings/variables. :-) But the point is worth making that there's a reason prefix and server home directory are distinct settings, and you've crystallized it quite well in the above. > The workaround you posted does work, but I'd prefer to use the defaults... It's not a "workaround." It's the correct way to override the default assumptions, one of those being that your system is properly configured, and that sendmail is in the correct location mandated by relevant standards. > and the default is flawed - it's hardcoded to SBIN/sendmail, however in our SL6 > install it's /usr/lib/sendmail which symlinks to mta-postfix. $ ls -Fla /usr/*/sendmail* lrwxrwxrwx. 1 root root 30 Jun 21 2011 /usr/lib/sendmail -> /etc/alternatives/mta-sendmail* lrwxrwxrwx. 1 root root 24 Jun 21 2011 /usr/lib/sendmail.postfix -> ../sbin/sendmail.postfix* lrwxrwxrwx. 1 root root 21 Jun 21 2011 /usr/sbin/sendmail -> /etc/alternatives/mta* -rwxr-xr-x. 1 root root 213616 Jun 2 2011 /usr/sbin/sendmail.postfix* That's on SL6, by the way. As you can see, the canonical location is, indeed /usr/sbin/sendmail. > configure script locates this correctly, but torque.spec inserts its own value > and breaks it. If you do not have /usr/sbin/sendmail on your system, your installation is broken and needs to be fixed. :-)
Whilst we don't use RPMs for Torque here I believe that building Torque RPMs with --prefix should not change where it looks for the sendmail binary. IMHO prefix should only affect where the package you are building is putting files, not where it is expecting to find system binaries. Regarding the correct location for sendmail, this FHS document explains it well: http://www.pathname.com/fhs/2.2/fhs-4.7.html # For historical reasons, /usr/lib/sendmail must be a symbolic link # to /usr/sbin/sendmail if the latter exists.
(In reply to comment #4) > Whilst we don't use RPMs for Torque here I believe that building Torque RPMs > with --prefix should not change where it looks for the sendmail binary. IMHO > prefix should only affect where the package you are building is putting files, > not where it is expecting to find system binaries. That's certainly a reasonable comment. Perhaps it should be changed to "/usr/sbin/sendmail" instead of "%{_prefix}/sendmail" to avoid this. Unfortunately, the auto-detection is unreliable and failure not properly flagged which is why the setting exists to begin with. Ultimately, the most correct solution might be to allow --with-sendmail to be specified without a path so that auto-detection can occur but make failure a fatal error. Too many times, mysterious behavior has eventually been tracked to non-fatal sendmail binary detection failures at RPM build time. :-/