New comment by tornaria on void-packages repository

https://github.com/void-linux/void-packages/pull/36640#issuecomment-1098184798

Comment:
> I don't think we should vender these headers here. My hope was that kernel-libc-headers would be easy to modify to add those headers, but looking through the kernel headers has convinced me that we don't want the trouble.

I'm sorry, I pushed without commenting. That was meant as a PoC only, indeed only a few structs and defines are needed. Everything seems to be part of the stable kernel ABI (because come on, they can't change these numbers or struct layout without breaking user space), but they are not exported as a kernel API (that's why they are not in kernel-llibc-headers) and as you say they don't look like they are meant for use in user space; the bluez project seems to have equal named but different headers on the kernel side and on the user side.

> I think you should drop the most recent two commits and go back to pulling in `libbluetooth-devel` in `python3` and breaking the (default) cycle in `bluez`.

Sure, that seems an easy option here.

----

About the circular dependency: https://wiki.gentoo.org/wiki/User:Sam/Portage_help/Circular_dependencies#Python_and_bluez

I wonder if there is a different (more general) way to break dependency cycles like this. Some packages have `chroot-*` versions for bootstrapping. Either `bluez` or `python` could have bootstrap packages, etc. although that could be a maintainance burden.

What about having a "bootstrap" build option (as opposed to a separate template) which has fewer dependencies, then have xbps-src use the bootstrap option to break circular dependencies. In this case, for instance, the difference for bootstrap bluez would be just removing `python3-docutils` from `hostmakedepends` and the difference for bootstrap python3 would be just removing `libbluetooth-devel` from `makedepends`.