Re: [Libguestfs] [libnbd PATCH v4 0/2] lib/utils: introduce async-signal-safe execvpe()

On Tue, Mar 21, 2023 at 03:56:22PM +0100, Laszlo Ersek wrote: ci/README.rst is informative on that regards; I'm impressed at what lcitool (from the libvirt-ci) project gives us for local reproducibility of repeating various CI build failures. Yeah, I remember the debates back when GNU coreutils was offered patches to choose to build a multiname binary - it fits with Alpine's goals and matches busybox's minimalist footprint, but it violates GNU Coding Standards (which state that in general, an application's behavior should not depend on argv[0], precisely so that renaming it doesn't change its behavior). That works, but is not always my favorite: it fixes CI, but does not help any developer on a similar platform. I probably would have tried this in the test itself (untested here): cp /bin/expr f cleanup_fn rm f requires ./f 1 + 1 # We insist on expr behavior independent of argv[0] which will then skip the test (exit status 77) if a renamed /bin/expr doesn't behave the same as the original. But since we haven't heard complaints from anyone using Alpine as their primary development box (or any other non-Alpine but otherwise-busybox setup), we can make that change when such a complaint arises, rather than adding even more churn to your latest series of patches. Another thought - instead of skipping the test when /bin/expr is underwhelming when renamed, we could rewrite the test to avoid that dependency altogether. After all, we are building a test-fork-safe-execvpe binary that does exactly what we say it should; we could hack up test-fork-safe-execvpe.c to depend on argv[0] (I know - using the very thing I don't like about busybox) so that when run by its usual name it performs the unit test, but when run by the basename of f, it does just enough for us to prove that we indeed executed our desired binary (whether that be emulating a subset of /bin/expr, or something else). But again, that's more effort to code up than just skipping the test on a platform that's less likely to be a primary development station in the first place. I didn't even pay attention to this one before you pointed it out; but it is indeed a bug in busybox now that POSIX is moving towards standardizing realpath, so I've filed it: https://bugs.busybox.net/show_bug.cgi?id=15466 -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org