synce-hal scripts being installed to an incorrect location

[Adam Williamson]

It was reported on the Mandriva Cooker mailing list:

http://lists.mandriva.com/cooker/2009-03/msg00930.php

that synce's hal scripts are being installed to the 'wrong' location.

Poking about a bit, I see this relevant change in synce-hal:

http://synce.svn.sourceforge.net/viewvc/synce/trunk/hal/configure.ac.in?r1=3679&r2=3693

which does a better check of whether the location is valid, but doesn't
change the default.

I guess this may be an issue of old HAL vs. new HAL - i.e. libdir/hal is
right for older versions, libdir/hal/scripts is right for newer ones. It
seems bad to have a default that will fail on newer distros, though (I
ran into this same problem on Fedora Rawhide). Perhaps a more
sophisticated way to set the default is needed?

[Adam Williamson]

Post by Adam Williamson
http://lists.mandriva.com/cooker/2009-03/msg00930.php
that synce's hal scripts are being installed to the 'wrong' location.
http://synce.svn.sourceforge.net/viewvc/synce/trunk/hal/configure.ac.in?r1=3679&r2=3693
which does a better check of whether the location is valid, but doesn't
change the default.
I guess this may be an issue of old HAL vs. new HAL - i.e. libdir/hal is
right for older versions, libdir/hal/scripts is right for newer ones. It
seems bad to have a default that will fail on newer distros, though (I
ran into this same problem on Fedora Rawhide). Perhaps a more
sophisticated way to set the default is needed?

OK, I've looked into this further. It's nothing like that complicated -
it's just flat out the wrong location.

The offending change in synce-hal is this one:

http://synce.svn.sourceforge.net/viewvc/synce?view=rev&revision=3544

more specifically:

http://synce.svn.sourceforge.net/viewvc/synce/trunk/hal/hal/Makefile.am?r1=3432&r2=3544&pathrev=3544

prior to that, the scripts were installed to libexecdir. Which is I
think a sort of old location, but does work. This change installs them
to libdir/hal instead.

I don't know who decided on that path, but it's just fundamentally
wrong. Up until hal 0.5.7 (February 2006), HAL scripts were intended to
be installed to datadir/hal/scripts (/usr/share/hal/scripts ). From
0.5.8 on, they are intended to be installed to libdir/hal/scripts
(/usr/lib/hal/scripts , or possibly /usr/lib64/hal/scripts ). But no
version of HAL has ever expected or supported them being installed in
libdir/hal .

The relevant bits of code in HAL, FWIW, are hald/hald.c ,
hald/Makefile.am and hald-runner/main.c . hald-runner/main.c around line
254 (depends what version of HAL you have) shows that the valid
locations are just whatever PATH variable hald-runner is called with.
hald/hald.c calls it with a PATH that includes the variables
PACKAGE_LIBEXEC_DIR and PACKAGE_SCRIPT_DIR . hald/Makefile.am defines
these as $(libexecdir) and $(libdir)/hal/scripts , respectively. So
that's why those are the two paths where hal scripts can be placed
(well, there and /usr/bin, which gets pulled in to the PATH somehow, I
didn't bother looking at how).

The point here is that we should simply change the location in
trunk/hal/configure.ac.in from:

hal_addon_dir="`pkg-config --variable=libdir hal`/hal"

to:

hal_addon_dir="`pkg-config --variable=libdir hal`/hal/scripts"

and that should solve the problem. This probably merits a new release,
as I think just about any install of synce-hal 0.13.1 just won't work by
default, because of this.

[Mark Ellis]

Post by Adam Williamson

Post by Adam Williamson
http://lists.mandriva.com/cooker/2009-03/msg00930.php
that synce's hal scripts are being installed to the 'wrong' location.
http://synce.svn.sourceforge.net/viewvc/synce/trunk/hal/configure.ac.in?r1=3679&r2=3693
which does a better check of whether the location is valid, but doesn't
change the default.
I guess this may be an issue of old HAL vs. new HAL - i.e. libdir/hal is
right for older versions, libdir/hal/scripts is right for newer ones. It
seems bad to have a default that will fail on newer distros, though (I
ran into this same problem on Fedora Rawhide). Perhaps a more
sophisticated way to set the default is needed?

OK, I've looked into this further. It's nothing like that complicated -
it's just flat out the wrong location.
http://synce.svn.sourceforge.net/viewvc/synce?view=rev&revision=3544
http://synce.svn.sourceforge.net/viewvc/synce/trunk/hal/hal/Makefile.am?r1=3432&r2=3544&pathrev=3544
prior to that, the scripts were installed to libexecdir. Which is I
think a sort of old location, but does work. This change installs them
to libdir/hal instead.
I don't know who decided on that path, but it's just fundamentally
wrong. Up until hal 0.5.7 (February 2006), HAL scripts were intended to
be installed to datadir/hal/scripts (/usr/share/hal/scripts ). From
0.5.8 on, they are intended to be installed to libdir/hal/scripts
(/usr/lib/hal/scripts , or possibly /usr/lib64/hal/scripts ). But no
version of HAL has ever expected or supported them being installed in
libdir/hal .
The relevant bits of code in HAL, FWIW, are hald/hald.c ,
hald/Makefile.am and hald-runner/main.c . hald-runner/main.c around line
254 (depends what version of HAL you have) shows that the valid
locations are just whatever PATH variable hald-runner is called with.
hald/hald.c calls it with a PATH that includes the variables
PACKAGE_LIBEXEC_DIR and PACKAGE_SCRIPT_DIR . hald/Makefile.am defines
these as $(libexecdir) and $(libdir)/hal/scripts , respectively. So
that's why those are the two paths where hal scripts can be placed
(well, there and /usr/bin, which gets pulled in to the PATH somehow, I
didn't bother looking at how).
The point here is that we should simply change the location in
hal_addon_dir="`pkg-config --variable=libdir hal`/hal"
hal_addon_dir="`pkg-config --variable=libdir hal`/hal/scripts"
and that should solve the problem. This probably merits a new release,
as I think just about any install of synce-hal 0.13.1 just won't work by
default, because of this.

It needs looking into, but that's why configure has the
--with-hal-addon-dir option. Distros fiddle so much that it can't be
perfect, and you can't guarantee that the configured hal libdir is the
same as synce-hal libdir. I'm afraid packagers need to start looking at
the configure options available. What hal really needs is perhaps a
pkgconfig variable fir this.

Mark

[Adam Williamson]

Post by Mark Ellis
It needs looking into, but that's why configure has the
--with-hal-addon-dir option. Distros fiddle so much that it can't be
perfect, and you can't guarantee that the configured hal libdir is the
same as synce-hal libdir. I'm afraid packagers need to start looking at
the configure options available. What hal really needs is perhaps a
pkgconfig variable fir this.

Still, I don't see why the default value for this should be one that
deviates from upstream code.

At least Mandriva, Fedora and Slackware stick with the upstream values
on this.

It would perhaps be useful if users of other distros (particularly SUSE,
Debian and Ubuntu) could run the test:

hald --daemon=no 2>&1 | grep 'allowed paths'

and see what it returns for them.

[Mark Ellis]

Post by Adam Williamson

Post by Mark Ellis
It needs looking into, but that's why configure has the
--with-hal-addon-dir option. Distros fiddle so much that it can't be
perfect, and you can't guarantee that the configured hal libdir is the
same as synce-hal libdir. I'm afraid packagers need to start looking at
the configure options available. What hal really needs is perhaps a
pkgconfig variable fir this.

Still, I don't see why the default value for this should be one that
deviates from upstream code.
At least Mandriva, Fedora and Slackware stick with the upstream values
on this.
It would perhaps be useful if users of other distros (particularly SUSE,
hald --daemon=no 2>&1 | grep 'allowed paths'
and see what it returns for them.

Ubuntu (and I would expect Debian :-

Runner started - allowed paths are
'/usr/lib/hal:/usr/lib/hal/scripts:/usr/bin'

Ah, now I see what they've done. /usr/lib/hal is libexecdir for hal on
deb based. I've changed this so often I'm getting downright sick of it,
aaaahhhhh ! I'll add it my ever increasing list.....

Actually I'm tempted to make using the configure option mandatory,
maybe.

Ta
Mark

[Adam Williamson]

Post by Mark Ellis

Post by Adam Williamson
It would perhaps be useful if users of other distros (particularly SUSE,
hald --daemon=no 2>&1 | grep 'allowed paths'
and see what it returns for them.

Ubuntu (and I would expect Debian :-
Runner started - allowed paths are
'/usr/lib/hal:/usr/lib/hal/scripts:/usr/bin'
Ah, now I see what they've done. /usr/lib/hal is libexecdir for hal on
deb based. I've changed this so often I'm getting downright sick of it,
aaaahhhhh ! I'll add it my ever increasing list.....
Actually I'm tempted to make using the configure option mandatory,
maybe.

Still, looks like /usr/lib/hal/scripts is the standard location which
should work everywhere. I really think it should just default to that.

[Mark Ellis]

Post by Adam Williamson

Post by Mark Ellis

Post by Adam Williamson
It would perhaps be useful if users of other distros (particularly SUSE,
hald --daemon=no 2>&1 | grep 'allowed paths'
and see what it returns for them.

Ubuntu (and I would expect Debian :-
Runner started - allowed paths are
'/usr/lib/hal:/usr/lib/hal/scripts:/usr/bin'
Ah, now I see what they've done. /usr/lib/hal is libexecdir for hal on
deb based. I've changed this so often I'm getting downright sick of it,
aaaahhhhh ! I'll add it my ever increasing list.....
Actually I'm tempted to make using the configure option mandatory,
maybe.

Still, looks like /usr/lib/hal/scripts is the standard location which
should work everywhere. I really think it should just default to that.

Right, I've had a good look and I agree, changed to hal/scripts in svn.

Mark