Hi!
It seems that the previous RHEL / Fedora maintainers just wiped out
nut_check_libhal.m4 completely to replace it with
HAL_CALLOUTS_PATH="${libexecdir}"
HAL_FDI_PATH="${datadir}/hal/fdi/information/20thirdparty"
and did autoreconf in the SPEC. We can no longer do this, because
autoconf that it shipped with RHEL is too old. The options are to find
out the reason why it fails, do autoreconf on another machine to make a
patch or move files manually in the SPEC.
On my host
[build...@servinet libexec]$ pkg-config --silence-errors --variable=libexecdir
hal
returns nothing, but
[...@servinet ~]$ if (test -d "/usr/lib64/hal"); then echo 1; fi
1
[...@servinet ~]$ if (test -d "/usr/libexec"); then echo 1; fi
1
So apparently Debian line takes precedence over the Redhat line (which
turns out to be useless). The next test for OpenSuse, by the way, will
only work on 32-bit platforms, because the lib path is hardcoded and
apparently will fail anyway, because they do have /usr/libexec.
Therefore, I suspect that the detection logic in nut_check_libhal.m4 is
broken. Is it indeed the case or I have to read some magic files for
enlightenment?
I would suggest to swap the order of Debian and Redhat lines and for
Redhat check against the existence of /etc/redhat-release which is
guaranteed to be there on all RH distributions.
I am no Suse or Debian expert.
--
Sincerely yours,
Yury V. Zaytsev
On Thu, 2010-02-25 at 19:18 +0100, Yury V. Zaytsev wrote:
> Hi!
>
> Is there any particular reason why NUT installs hal addons to
>
> /usr/lib64/hal/hald-addon-bcmxcp_usb
> /usr/lib64/hal/hald-addon-megatec_usb
> /usr/lib64/hal/hald-addon-tripplite_usb
> /usr/lib64/hal/hald-addon-usbhid-ups
>
> Instead of /usr/libexec/hald-addon-* where they should actually be
> placed on RHEL systems?
>
> Is there a way to change this behavior with a ./configure option?
>
_______________________________________________
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
