I recently noticed that the gentoo ebuild for v1.9 has hard dependency on libbsd even though v1.9 doesn't require it (I'll open a PR to fix this on the next version bump).
This lead to me to realize that the suggestion we give in the README:
if ./configure --enable-libbsd-feature-test returns true
This option is intended to be used by package maintainers.
...is extremely unsound.
Dependencies cannot be dynamically probed
In pretty much all the distro package managers I'm aware of, dependencies need to be statically declared so that the package manager can install them before starting to install the package itself. This means that you cannot just invoke configure script during the build process and adjust dependency list based on that dynamically.
Which means that on every release the packager needs to manually run ./configure --enable-libbsd-feature-test to figure out if libbsd is needed or not. But this is still unsound because...
No awareness of what is coming from third-party packages
Most musl based distro seem to have some sort of package for headers like sys/queue.h (bsd-compat-header on alpine, sys-libs/queue-standalone on gentoo etc). On most systems, these will end up getting installed as some dependency for some other package. But autoconf doesn't know that, it will see sys/queue.h exists and declare that libbsd is not needed - and if the packager follows that then that package will be broken on a minimal install which doesn't have compat headers installed.
Which means running that command has to be done inside a minimal chroot/container. But even that is still unsound because...
No awareness of "system set"
Most distro have some sort of "system set" - which is all the packages that are needed for a bare/base system. The bsd-compat-header for example might not be part of the system set, but some package in the system set (let's say P) might be pulling it in. So the configure check will say libbsd is not needed but if P is removed from the system set or stops depending on sys/queue.h then the scrot package will be broken because sys/queue.h will now be missing on a minimal install.
Possible solutions
Either very explicitly document these pitfalls.
Or remove this check entirely and more rigorously document non-standard functions that we use.
In my (limited) packaging experience, the latter option is more useful. If I see that something needs err.h and sys/queue.h - I know err.h is not a problem on the libcs that gentoo supports (most distros support only a single libc). And for musl I can make a better informed decision to use the more lightweight sys-libs/queue-standalone instead of the more heavyweight libbsd.
I recently noticed that the gentoo ebuild for v1.9 has hard dependency on
libbsdeven though v1.9 doesn't require it (I'll open a PR to fix this on the next version bump).This lead to me to realize that the suggestion we give in the README:
...combined with this comment:
...is extremely unsound.
Dependencies cannot be dynamically probed
In pretty much all the distro package managers I'm aware of, dependencies need to be statically declared so that the package manager can install them before starting to install the package itself. This means that you cannot just invoke
configurescript during the build process and adjust dependency list based on that dynamically.Which means that on every release the packager needs to manually run
./configure --enable-libbsd-feature-testto figure out if libbsd is needed or not. But this is still unsound because...No awareness of what is coming from third-party packages
Most musl based distro seem to have some sort of package for headers like
sys/queue.h(bsd-compat-headeron alpine,sys-libs/queue-standaloneon gentoo etc). On most systems, these will end up getting installed as some dependency for some other package. But autoconf doesn't know that, it will seesys/queue.hexists and declare that libbsd is not needed - and if the packager follows that then that package will be broken on a minimal install which doesn't have compat headers installed.Which means running that command has to be done inside a minimal chroot/container. But even that is still unsound because...
No awareness of "system set"
Most distro have some sort of "system set" - which is all the packages that are needed for a bare/base system. The bsd-compat-header for example might not be part of the system set, but some package in the system set (let's say
P) might be pulling it in. So the configure check will say libbsd is not needed but ifPis removed from the system set or stops depending onsys/queue.hthen the scrot package will be broken becausesys/queue.hwill now be missing on a minimal install.Possible solutions
In my (limited) packaging experience, the latter option is more useful. If I see that something needs
err.handsys/queue.h- I knowerr.his not a problem on the libcs that gentoo supports (most distros support only a single libc). And for musl I can make a better informed decision to use the more lightweightsys-libs/queue-standaloneinstead of the more heavyweightlibbsd.