FS#49771 - makepkg: fstatat broke portability with <= macOS 10.9
Attached to Project:
Pacman
Opened by ilovezfs (ilovezfs) - Sunday, 19 June 2016, 17:01 GMT
Last edited by Allan McRae (Allan) - Tuesday, 11 October 2016, 10:27 GMT
Opened by ilovezfs (ilovezfs) - Sunday, 19 June 2016, 17:01 GMT
Last edited by Allan McRae (Allan) - Tuesday, 11 October 2016, 10:27 GMT
|
Details
makepkg now calls fstatat, which is only available for macOS
>= 10.10
fstatat was introduced in https://git.archlinux.org/pacman.git/commit/?id=16718a21 See https://github.com/Homebrew/homebrew-core/pull/2102 It would be great if upstream could find an alternative to using fstatat given that it appears to be called only once in the makepkg codebase. If not, unfortunately this means Homebrew will have to drop support for makepkg on Mavericks in order to ship 5.0.1, or find some kind of work around such as bolting on an implementation of fstatat from gnulib or elsewhere (e.g., OpenZFS on OS X has one). For obvious reasons, an upstream "fix" would be much preferred. Thanks for considering in this! I understand that using fstatat on code primarily intended for Linux is not a bug per se, but it would be great if portability could be restored. |
This task depends upon
Closed by Allan McRae (Allan)
Tuesday, 11 October 2016, 10:27 GMT
Reason for closing: Fixed
Additional comments about closing: git commit be1ffeda
Tuesday, 11 October 2016, 10:27 GMT
Reason for closing: Fixed
Additional comments about closing: git commit be1ffeda
```
iMac-TMP:~ joe$ ls /usr/local/Cellar/makepkg/5.0.1/bin/
cleanupdelta pacman-db-upgrade pactree repo-remove
makepkg pacman-key pkgdelta testpkg
makepkg-template pacman-optimize repo-add vercmp
pacman pacsort repo-elephant
```
which means libalpm does get built. I guess we could try to selectively strip out any of them using libalpm, unless there's a configure option that can do that? It would be helpful if configure/make/make install worked.
Note that just running `make install` only inside the scripts directory leads to test failure (because makepkg, though installed, doesn't work at all).
I've taken to doing this, which does result in a functional makepkg after a "regular" make install from the top source directory:
```
diff --git a/lib/libalpm/hook.c b/lib/libalpm/hook.c
index 6890a6e..99f6799 100644
--- a/lib/libalpm/hook.c
+++ b/lib/libalpm/hook.c
@@ -676,12 +676,14 @@ int _alpm_hook_run(alpm_handle_t *handle, alpm_hook_when_t when)
continue;
}
+#if 0
if(fstatat(dirfd(d), entry.d_name, &buf, 0) != 0) {
_alpm_log(handle, ALPM_LOG_ERROR,
_("could not stat file %s: %s\n"), path, strerror(errno));
ret = -1;
continue;
}
+#endif
if(S_ISDIR(buf.st_mode)) {
_alpm_log(handle, ALPM_LOG_DEBUG, "skipping directory %s\n", path);
```
But this patch is pretty unacceptable for an in-formula patch, and I'd prefer not to have to vendor it forever (and update it every time it breaks) in our separate formula-patches repository. It would be easier to just bolt on fstatat with gnulib and be done with it.
But it would be really great if upstream could make the code portable again out of the box given that the call to fstatat occurs exactly one time, and the work around is literally to just chdir to the directory, run regular fstat, and then chdir back where you started.