Many distributions customize their hal libexecdir. Other packages need this value to be able to install addons to correct location. The convenient way to do such things is providing the path in the pkgconfig file, which may simplify building of other packages.
Created attachment 16263 [details] [review] hal-pc-paths.patch Proposed fix, which will allow: pkg-config --variable=libexecdir hal pkg-config --variable=hal_script_dir hal It uses paths defined in bug 15767 and may need rework, if better path definition mechanism will appear. For convenience, I can prepare HAL_CHECK configure.ac macro, which may check for hal version and set paths (as it lacks in hal, third parties already do it - e. g. network UPS tools).
Looks good to me if we change it to +hal_libexecdir=@libexecdir@ +hal_scriptdir=@libexecdir@/scripts
(In reply to comment #2) > Looks good to me if we change it to > > +hal_libexecdir=@libexecdir@ > +hal_scriptdir=@libexecdir@/scripts > Hmm, seems this depends on bug 15767. I think it should be +hal_libexecdir=@libexecdir@ +hal_scriptdir=@libdir@/hal/scripts with the ways things currently work.
Created attachment 19102 [details] [review] hal-paths.patch Here is much larger patch, which gets rid fixed paths in hal and introduces two new configure options: --with-hald-addon-dir and --with-hald-script-dir The default behavior after patching is the same as before; this patch does NOT address bug 15767. It will be addresses in a separate patch. New features introduces: pkg-config file supports two new options: pkg-config --variable=hald_scriptdir hal pkg-config --variable=hald_addondir hal Provided hal.m4 with a new autoconf macro: HAL_PATHS_INIT helps to prevent uncertainty of hal paths. For patched hal, it uses hal.pc to detect paths, for old hal it checks probable paths to detect the correct destination. Tests performed: Without additional configure options it behaves as before. --libexecdir works as before With options, all addons and scripts from snapshot 20080828 are completely moved to defined location. After applying, you have to check, that the patch is still complete by: --with-hald-addon-dir=/newpath --with-hald-script-dir=/newpath/scripts. The old location must stay empty.
Ping. The last patch (plus patch in bug 15767) allow clean definition of all HAL paths, but allows distros to stay in old directories. It also adds a smart way to deteremine addon and script dirs. Note: I don't know defaults in particular distributions, but maybe adding ${bindir} ${sbindir} /usr/bin /usr/sbin to both search paths would be useful.
I missed that bug, sorry. A simple solution to use --libexecdir=/usr/lib/hal is now in git HEAD. I hope that is good enough. Otherwise let me know.
The bug asks to "provide a convenient way to query for addon dir". But there is no way to query for libexecdir - http://cgit.freedesktop.org/hal/tree/hal.pc.in lacks libexecdir. You need to add it to hal.pc.in: +libexecdir=@libexecdir@ hal.m4 from the patch may be (after modification of the "new style" pkg-config query) still useful for third party software developers who want to provide addons that should work in all distros with all hal versions. I can provide an updated hal.m4.
The approach sounds right, but we have always /usr/lib/hal/scripts now, which is good enough I think. I doubt we will change any package to use that new query. HAL is unmaintained, and will no longer be developed, and the goal is to get rid of it. :) If it's not solving any real problem we have, please close this bug, otherwise move the discussion to the hal-devel list and check if someone needs that. :)
It was intended to help in packaging of third party addons and scripts, that need to detect correct directory. It would be useful for package like hal or openct. Even if hal is unmaintained, adding the single line to .pc file may be a good idea. But if you want to keep things as they are, it is possible to recycle hal.m4 in each third party project that need this detection.
(In reply to comment #9) > It was intended to help in packaging of third party addons and scripts, that > need to detect correct directory. It would be useful for package like hal or > openct. > > Even if hal is unmaintained, adding the single line to .pc file may be a good > idea. > > But if you want to keep things as they are, it is possible to recycle hal.m4 in > each third party project that need this detection. Sure, as said, if it solves a problem, send it to the list, and let's apply it if people find it useful. It's just that there should be no new packages using HAL, and old packages likely don't change to the new query now. :)
Oh, and as you mention openct, that needs to drop HAL support soon, and convert to udev.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.