Bug#915423: xfce4-session: reproducible build (usrmerge): embeds path of rm found via PATH
Hello,
On Sun, Dec 09, 2018 at 03:12:28PM +0100, Yves-Alexis Perez wrote:
> I didn't follow recent discussions on usrmerge, but are we sure explicitly
> adding snippets like this to every relevant package is the right way to fix
> that? It looks a bit hacky to me (also couldn't that be done in debhelper or
> something?).
What the "right" way to fix it can easily become a bit of a
philosophical discussion. Passing the variables explicitly to configure
is the *documented* autotools way of handling it.
It seems to me like autotools tries alot to cater to arcane proprietary
unix systems and similar where system tools generally can't be expected
to behave sanely in most cases and you need to build in the specific
path to the sane (gnu?) version instead. I'm not sure why in your case
AC_PATH_PROG was considered, because I'm not aware of systems where
the rm command can't be considered sane. A better approach in general,
specially when dealing with a free software system where we can fix
the system tools if they don't behave sanely, would be to just trust
the runtime PATH, instead of hardcoding the result from the *build*
environment.
In your case the RM_CMD define is passed to g_spawn_sync function.
That function takes a flags argument where you could add
G_SPAWN_SEARCH_PATH. The envp argument is already being passed NULL
which means that the environment is inherited from the parent process.
I assume that one has a sane PATH set, but with things like session
managers you might need to pay special attention to the environment it
runs in/from.
Please also note that you can't pass RM=rm because (for unknown reasons)
the generated configure script (in your case, and most cases, but not
all) the passed value is checked to be a full path and if not then it's
ignored. You'll thus have to patch in both the "Search PATH" flag and
somehow bypass the RM_CMD configure logic, if you want to do down
that road instead of using the simple solution Ansgar already provided.
Regards,
Andreas Henriksson
Reply to: