Bug#1006996: mate-polkit: On arm64 architecture mate-polkit tries to open an amd64 file and fails
On Thu, 1 Dec 2022, Simon McVittie wrote:
Forwarding this from -devel since I'm not sure whether you saw it there.
[...]
On Fri, 18 Nov 2022 at 22:23:05 +0000, Mike Gabriel wrote:
> The flaw in mate-polkit is that the
> /etc/xdg/autostart/<polkit-agent>.desktop file so far has been shipped in
> mate-polkit-common (which usually got built on amd64 builders) and that that
> .desktop file contains a multi-arch path in the Exec= key.
Probably a silly question, but could you build mate-polkit with
--libdir=/usr/libexec instead of /usr/lib/x86_64-linux-gnu/polkit-mate,
so that the polkit auth agent is at a location that does not vary between
architectures?
mate-polkit is currently Multi-Arch: same, but that seems wrong to me:
on a dual-architecture amd64/i386 system (or arm64/armhf or any other
combination), there is no point in running more than one architecture's
copy of the MATE polkit authentication agent. They'll all have the same
UI and the same behaviour, so any single architecture is enough. This
seems like a textbook case of a Multi-Arch: foreign package.
I do agree with Simon. It really seems to make sense to use /usr/libexec
as location (as a quick solution at least). polkit-agent-helper-1 from
the package policykit-1 for instance is also there.
(On amd64 it would maybe be nice to leave behind a symlink
/usr/lib/x86_64-linux-gnu/polkit-mate/polkit-mate-authentication-agent-1 ->
/usr/libexec/polkit-mate-authentication-agent-1 so that if a sysadmin has
edited the conffile and therefore doesn't receive the new version, then
the agent will still start. But that's an optional quality-of-implementation
thing.)
It's the other way around. Nobody needs to change a configuration file on
an amd64 system because this is the only architecture where that path is
correct. Anyway, I guess the user would be asked by dpkg during upgrade
whether to install the new configuration file if it is kept in
mate-polkit-common and there are already local changes. So I am not quite
sure if that additional symlink is really needed.
Another possible solution to this would be to not install an XDG
autostart file into /etc at all, and instead do one or more of these:
1. teach MATE to read additional autostart files from a location below
/usr as a lower priority than XDG_CONFIG_DIRS, for instance if it
is currently reading
[g_get_user_config_dir() + "/autostart",
x + "/autostart" for x in g_get_system_config_dirs().split(":")]
then that could be changed to
[g_get_user_config_dir() + "/autostart",
x + "/autostart" for x in g_get_system_config_dirs().split(":"),
"/usr/share/mate/autostart"]
2. launch this polkit agent programmatically in MATE code (perhaps via
D-Bus activation) instead of relying on XDG autostart as a way to
discover it
3. integrate it into the desktop shell so it doesn't need to be launched
separately at all
[...]
I like the second proposal quite much. It would be good if
mate-session-manager could take care of it.
Although I fully understand the benefits of the third proposal, I doubt
that the MATE developers will go this way. Some of the MATE components
are also used in X11 environments that are not MATE (e.g. awesome or i3wm)
because these components are still kind of stand-alone and not bundled
like their counterparts in GNOME.
However, I guess that this is something that should rather be discussed
and dealt with upstream.
I think that moving polkit-mate-authentication-agent-1 to /usr/libexec
and updating debian/control appropriately would be just enough to close
this ticket.
Cheers,
Thomas
Reply to: