Bug 51617

Summary:	polkitd and polkit-agent-helper-1 get installed in libprivdir which is not multilib compatible
Product:	PolicyKit	Reporter:	Samuli Suominen <ssuominen>
Component:	daemon	Assignee:	David Zeuthen (not reading bugmail) <zeuthen>
Status:	RESOLVED NOTABUG	QA Contact:	David Zeuthen (not reading bugmail) <zeuthen>
Severity:	major
Priority:	medium	CC:	freedesktop-bugs
Version:	unspecified
Hardware:	x86-64 (AMD64)
OS:	All
Whiteboard:
i915 platform:		i915 features:

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.