Bug 15768

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.