Hi, recently USE=bpf was added to systemd which in turn need CONFIG_BPF_LSM and CONFIG_DEBUG_INFO_BTF. If the latter is enabled, the kernel needs pahole at build-time (for other kernel configs enabled on the way). I’m unsure how to track this properly, as users can use plenty different kernels - maybe add a postinst warning for the systemd package? Best regards, Nils Reproducible: Always
gentoo-kernel[debug] handles this for you. I'm not sure what else we could do though, because the same thing applies to e.g. cpio, and then people have to install it manually. i.e. If you want Portage to handle your kernels, let it?
FWIW, the kernel help text mentions pahole too: https://cateee.net/lkddb/web-lkddb/DEBUG_INFO_BTF.html
So what happens if you run systemd with USE=bpf enables, and the kernel is missing those options?
The systemd README file documents this requirement. This feature seems like it will be seldom used, so I don't really feel like we need to advertise the kernel requirements. People can read the documentation. Maybe mention the README file in the USE flag description?
(In reply to Mike Gilbert from comment #3) > So what happens if you run systemd with USE=bpf enables, and the kernel is > missing those options? See https://github.com/systemd/systemd/issues/32968. But the ebuild *already* checks for these config options, it's just that OP wants us to mention pahole.
Ah I see. I don't think it makes sense for the systemd ebuild to document tools required by the kernel build system.
(In reply to Sam James from comment #5) > [...] it's just that OP wants us to > mention pahole. Excactly. (In reply to Mike Gilbert from comment #6) > Ah I see. I don't think it makes sense for the systemd ebuild to document > tools required by the kernel build system. I still disagree as I see it's as an unusual feature that is necessary for a certain USE flag of systemd (only?) and is slightly annoying when you stumble upon it. No show-stopper, but your kernel does not compile which is highly unusual and needs manual intervention and inspection. Anyways, you're the maintainer, you decide ;) I'll close this as resolved-cantfix (for the record, none of the resolved flags really fits well here in my opinion).
