Bug 304316

We use this in configure:

%configure                                                      \
        --libexecdir=%{_libexecdir}/hal                         \

if _libexecdir is on 64bit /usr/lib64 someone should may fix _libexecdir or not? Not sure if this is really a HAL problem

Bug 157894 was cosidered as INVALID. So using the default incorrect %{_libexecdir} should be considered as deprecated.

1) why is there no warning about use %{_libexecdir} in our build system if it is deprecated?
2) why should someone try to mix a 64bit HAL package with (external, not with hal.rpm shipped addons) 32bit addons? The addons need libhal and this is already 64bit on a 64bit system. 

I don't see atm the advantage of changing --libexecdir

1. See bug 157894. %{_libexecdir} is not deprecated, only the default value is bad. Other distros have bad value as well, we are bug-compatible. But we are bi-arch, so our packages may break.

2. Well, hal is definitely not affected by libexecdir badness:

grep /usr/lib64/hal $(rpm -ql hal)
Binary file /usr/sbin/hald matches

No library is affected, only hald matches.

So yes, just now there is no advantage and no disadvantage.

I reported this bug against all packages using bad inside %{_libdir}. Real brokenness appears, only:

1. libexecdir is inside /usr/lib64
and
2. grep libexecdir_of_the_package $(rpm -ql package_name) returns any match in shared library on 64-bit system
and
3. we provide -32bit package with this library
and
4. we do not provide libexecdir helpers in -32bit package (not providing is a default behavior)

Thanks for the information.

If hal is not addected by this problem and if there are no advantages in changing the current hal.spec, I close the bug for now as WONTFIX.

Reopening.

I did not notice another way, how it could break:

Third party supplier provides hal addon, which is 32-bit only.

I think that it could work on 64-bit system without any problem, but it will not.

Hald daemon will read FDI file and search for addon in /usr/lib64/hal. But the addon will be installed to /usr/lib/hal and will not be found.

It would be nice to fix it for 11.1 and SLES11.


There are upstream problems related: hald_runner correctly uses PACKAGE_LIBEXEC_DIR, but PACKAGE_SCRIPT_DIR is (very probably incorrectly) derived from libdir. Reporting as https://bugs.freedesktop.org/show_bug.cgi?id=15767

This upsteam problem has to be fixed first.

And yet another related (upstream) problem: hal.pc provides no way to detect location of hald addon directory. Reporting as https://bugs.freedesktop.org/show_bug.cgi?id=15768

How can you run 32bit addon against a 64bit libhal (which is needed by all HAL addons) and a 64bit HAL?

32bit addon will link against hal-32bit, which is part of our distribution.

Addons are binaries, so architecture does not need to match architecture of the caller (even if starting from library, but hal addons are started by hald). I did not tested bi-arch addon, but I see no reason, why it will not work (except this bug).

There are now comments on the bugs you filed on fd.o. Could you please take a look at it and comment?

Yes, I will do it and provide comments on the consensus.

Stanislav, any update here?

I have just provided a new patches to the upstream bugzilla.

They are safe to apply, but you have to decide about new defaults:

- Use --libexecdir=%{_libdir}/hal: keep compatibility, keep bi-arch problems (32-bit scripts can't work in 64-bit distributions)

- Use --libexecdir=%{_prefix}/lib/hal: break compatibility, but fix bi-arch problems (32-bit scripts can work in 64-bit distributions)

If you decide the second, you can create compatibility symlink. Due to RPM brokenness it is a bit complicated, but possible e. g. in %post (untested):

%post
%if %{_lib} != lib
mv 2>/dev/null usr/lib64/hal/* . || :
rmdir 2>/dev/null usr/lib64/hal || :
mkdir -p usr/lib64
ln -s ../lib/hal usr/lib64/hal
%endif

Patch is already provided and waiting for review:

https://bugs.freedesktop.org/show_bug.cgi?id=15768#c4

I didn't see this bug earlier, sorry.

In the meantime, it's fixed upstream:
http://cgit.freedesktop.org/hal/commit/?id=fa05be92c4b924ce6a791d2e7c46a467cccf357e

And the package without "lib64" is in Factory. If that's still missing something, please let me know.