Bug 51617 - polkitd and polkit-agent-helper-1 get installed in libprivdir which is not multilib compatible
Summary: polkitd and polkit-agent-helper-1 get installed in libprivdir which is not mu...
Status: RESOLVED NOTABUG
Alias: None
Product: PolicyKit
Classification: Unclassified
Component: daemon (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) All
: medium major
Assignee: David Zeuthen (not reading bugmail)
QA Contact: David Zeuthen (not reading bugmail)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-01 05:13 UTC by Samuli Suominen
Modified: 2012-07-02 09:20 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Attachments

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/

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.