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