Bug#1006996: Bug #1006996: mate-polkit: On arm64 architecture mate-polkit tries to open an amd64 file and fails
Forwarding this from -devel since I'm not sure whether you saw it there.
----- Forwarded message from Simon McVittie <smcv@debian.org> -----
Date: Sat, 19 Nov 2022 11:44:34 +0000
From: Simon McVittie <smcv@debian.org>
To: debian-devel@lists.debian.org
Subject: Re: Bug #1006996: mate-polkit: On arm64 architecture mate-polkit tries to open an amd64 file and fails
Message-ID: <Y3jBohhqP8q/EpdO@momentum.pseudorandom.co.uk>
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.
(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.)
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
People who have been thinking about image-based OSs are already trying to
move the community towards a model where the "factory-installed" state
of /etc is empty, and every file in /etc represents a local divergence
from that original state (sysadmin configuration). I think that's a
good goal in general: /etc has traditionally been a mixture of sysadmin
configuration (/etc/fstab, /etc/hostname) and system-integration glue
(/etc/ld.so.conf.d, /etc/xdg/autostart), and if we separated those two,
it would become a lot more obvious what is sysadmin configuration and
what is part of the OS.
Solving the problem of "the design of /etc/xdg/autostart conflicts with
wanting a factory install to have an empty /etc" *in general* is hard
because it's an interoperability point between multiple desktop environments
(e.g. people don't want to break /etc/xdg/aa-notify.desktop), so changing
it in an interoperable/consistent way requires changing the spec and every
implementation. For instance some people are advocating changing the
autostart spec so that implementations will read
/usr/etc/xdg/autostart/*.desktop or /usr/etc/autostart/*.desktop or
/usr/share/xdg/autostart/*.desktop or some standardized path like that.
AIUI there's currently no real consensus on specific paths.
However, solving it for a component that has OnlyShowIn=MATE is easy,
because by design only MATE is going to launch that component anyway -
so it's entirely reasonable for it to rely on implementation-specific
MATE behaviours. For instance, if MATE developers decided that they are
going to read /usr/share/mate/autostart as an additional search path
component of lower priority than $XDG_CONFIG_DIRS/autostart, then that
wouldn't harm interoperability with other desktops and is something
that MATE can do unilaterally.
Alternatively, integrating the polkit agent into the desktop shell is
what GNOME does: GNOME's polkit agent is part of GNOME Shell, which
has some other advantages, such as the compositor (which is also Shell)
being able to give it special handling around input-grabbing to protect
the secure input path.
If you evaluate those options and decide that you still need
conffile handling for /etc/xdg/autostart/*.desktop here:
> To simplify life (and yes, this is debatable): Do situations exist, where an
> enforced conffile update (overwriting it) is allowed / justifiable?
The Policy requirement is not "don't overwrite conffiles", the Policy
requirement is "don't revert sysadmin changes". Doing the overwrite
correctly is not going to be trivial (particularly where dpkg conffiles
interact with moving files between packages), but one technique that
I've seen used is to hard-code one or more known md5sums of unmodified
"old" conffiles with the bad path in them, and overwrite the file with
the new, "good" version if and only if it matches one of those.
smcv
----- End forwarded message -----
Reply to: