Bug 51617 - polkitd and polkit-agent-helper-1 get installed in libprivdir which is not multilib compatible
polkitd and polkit-agent-helper-1 get installed in libprivdir which is not mu...
Status: RESOLVED NOTABUG
Product: PolicyKit
Classification: Unclassified
Component: daemon
unspecified
x86-64 (AMD64) All
: medium major
Assigned To: David Zeuthen (not reading bugmail)
David Zeuthen (not reading bugmail)
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-01 05:13 UTC by Samuli Suominen
Modified: 2012-07-02 09:20 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Samuli Suominen 2012-07-01 05:13:19 UTC
32bit ELFs go to /usr/lib32, 64bit ELFs go to /usr/lib64

/usr/lib64 is a symlink in non-true-multilib systems, like Gentoo AMD64, to /usr/lib so everything will work

but it is NOT a symlink on MIPS 64EL systems with 3 different ABIs, hence we see the following:

** (process:7239): WARNING **: Cannot spawn helper: Failed to execute child process "/usr/lib/polkit-1/polkit-agent-helper-1" (No such file or directory)

The hardcoded path is in:

helper_argv[0] = PACKAGE_PREFIX "/lib/polkit-1/polkit-agent-helper-1";

And:

"libprivdir" in src/polkitagent/Makefile.am

Any reason why these 3 binaries don't respect the multilib dir, but other files installed by polkit do? Like all the libraries it installs...

This is also not configurable by any --libexecdir switch which is very inconvinient, so far I'm using quite ugly sed-job in the polkit's packaging to overcome this...
Comment 1 Samuli Suominen 2012-07-01 05:19:20 UTC
(In reply to comment #0)
> Any reason why these 3 binaries don't respect the multilib dir, but other files

*2 binaries (typing error...)
Comment 2 Kay Sievers 2012-07-02 08:32:19 UTC
/usr/lib/<pkgname>/ is a directory like /usr/libexec/ or even /bin. It shares
absolutely zero things with the arch-specific $libdir ,or lib64/.

/usr/lib/<pkgname>/ is the canonical "application private directory". It has
the multi-lib or arch-specific rules as /bin.

It just happens to be the same directory as $libdir for 32bit installations
in the classic non-multi-arch layout, which might go away over time, but that
is absolutely no reason to symlink it away.

Having /lib pointing to /lib64 is plain wrong, and should not explicitly
be supported by upstream build systems. If it happens to be that libexecdir
works for that, then it's fine, but it is surely not treated as a bug if it
isn't.

The directories are part of the de-facto ABI between the CoreOS components.
They are not public like bin/ or /usr/share/, but part of the contract
between the involved parties working on the basic system components. And
these directories are not meant to be changed for proper interoperability.

It's the same as /lib/udev/, which is surely not /lib64/udev/. Misguided
things like that should just be fixed, to remove the needless differences
between the Linux distributions.
Comment 3 David Zeuthen (not reading bugmail) 2012-07-02 08:35:21 UTC
Thanks for explanation Kay, you expressed it much better than I could have. Closing NOTABUG as there's no bug here.
Comment 4 Samuli Suominen 2012-07-02 09:20:41 UTC
I sort of expected this answer. Thanks for clarifying. 

I filed http://bugs.gentoo.org/424423 to clean up Portage's multilib check that currently bails out on the 64bit ELF in /usr/lib/