This is primarily an RFC issue to discuss possible ways forward wrt. bpftool & libbpf packaging. dev-util/bpftool and dev-libs/libbpf are currently packaged separately. As bug #941185 has shown, this can create ABI & API problems, as bpftools's internal libbpf must match the external libbpf (runtime .so, headers). Unfortunately upstream's versioning for bpftool is severely inconsistent; this makes packaging from a kernel tree very challenging, as different releases may be wildly different in terms of API and ABI while still advertising the same version number. It's not really easy to enforce that matching ebuild versions are installed since neither bpftool nor libbpf depend on each other, so one possibility is to merge both packages into one. In practically all instances where libbpf is used, bpftool is also required. Reproducible: Always
As a first step for a combined build (as mentioned in #941185 and above) I started with bpftool and added a few lines to also build libbpf from the kernel tree. That was easy enough and works fine; it builds and installs all of bpftool and libbpf/headers/pkgconfig in a consistent manner. The one downside of the (historic and inherited by me) kernel-tree based build for bpftool is that we lose track of the libbpf cadence and their releases/version numbers on Github. These releases always trail the in-kernel code by a mile and may be outdated (see below for more). After taking a break and clearing my head I realized that a similar, but alternative route exists. The libbpf project also publishes bpftool releases to Github, and as it turns out there is an archive with both bpftool _and the matching libbpf version bundled_. I believe someone mentioned this to me previously (Joonas or Patrick - don't remember). By having a combined ebuild from that tarball we could: - simplify the bpftool ebuild to no longer require the kernel tree unpacking/patching, which is pretty fragile - have a single version number for the ebuild - have matching versions between bpftool and libbpf, regardless how bonkers upstream's "version" numbers are What we don't get from the combined bpftool-libbpf tarball is a major.minor.patch version for libbpf..which we wouldn't need with a combined package using the bpftool version. Unfortunately libbpf is updated more frequently with bugfixes than bpftool. One way around that is to use the Github bpftool release cadence and instead of using the combined tarball, add a matching libbpf release as libbpf subdirectory (what I do with sysdig & falcosecurity-libs). bpftool would then have a major.minor version and libbpf patch releases could be managed by ebuild revbumps, if necessary. That way both are still consistent, but also up-to-date as necessary. The downside of all this is of course that no matter how we move this cheese, we'll have to touch all ebuilds and migrate them from libbpf and/or bpftool to the unified ebuild (bpftool/bpf-tools..). Not difficult, but. Any other ideas?
As experiment I now has a bpftool build that uses the Github artifacts for both bpftool and libbpf (cvan be split up if necessary). Obviously it does not work the same way as the kerne-tree based build because the feature detection is broken. Thanks binutils.
So after fixing upstream's feature detection on the Github mirror I now have an -9999 ebuild for bpftool that can correctly: - build from the master branch with libbpf as submodule - build a version from the same repo with whatever libbpf is bundled - optionally use a newer libbpf version (for patch updates). I also played a bit with a fat ebuild aka installing both bpftool and libbpf at once. bpftool-also-installing libbpf was easy (a few lines); libbpf-also-installing bpftool (with USE=tools) was less easy because of somewhat hairy build overriding. I don't particularly like either option since they do not allow properly depending on bpftool/libbpf as BDEPEND/RDEPEND. The virtual approach mentioned in #941185 also seems more complicated than necessary. Maybe adding slots and a warning in pkg_pretend() (against installed slot or version mismatches) can be done in the future, simply to prevent people from mixing random versions. I don't know if that's a good practice. So for the next releases (probably coming with kernel 6.12) I suggest we just bump libbpf regularly, add the bpftool-9999 ebuild & create a matching bpftool-7.5.0-r3 from that.
After spending an unreasonable amount of time trying to find the rules for bpftool/libbpf compatibility, the mystery is solved: there are none. Yay. The problem we encountered with scx was a cascade of bugs between bpftool and libbpf, resulting in the mismatched code generation. These are/will be fixed in both bpftool and libbpf upstream via new mechanisms for feature detection in libbpf, i.e. it is something that packages using libbpf need to do, e.g. checking MAJOR/MINOR version macros etc. So there is no need for us to somehow couple these things together via slots, virtuals or anything else.
Relevant commits for this are e.g.: bpftool: Allow compile-time checks of BPF map auto-attach support in skeleton https://github.com/libbpf/bpftool/commit/aa95345f73226a00c5ab46d84eb227bf5dc6b4a4 bpftool: improve skeleton backwards compat with old buggy libbpfs https://github.com/libbpf/bpftool/commit/1b935a7f34428f29caf8ea5cf73b32018d4cd5bb
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=62f540484b263a6b31edb273cf5665ead1e9f0d1 commit 62f540484b263a6b31edb273cf5665ead1e9f0d1 Author: Holger Hoffstätte <holger@applied-asynchrony.com> AuthorDate: 2024-10-23 13:03:29 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-10-30 22:28:34 +0000 dev-util/bpftool: add rewritten live ebuild for Github-based bpftool mirror This new ebuild for bpftool gets rid of the fragile kernel-tree based build and uses the Github-based mirror repository. Unlike the previous ebuilds it allows well-defined version upgrades and optionally makes bundling a newer, properly versioned libbpf easy and reproducible. No more mystery meat! Closes: https://bugs.gentoo.org/941248 Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com> Signed-off-by: Sam James <sam@gentoo.org> dev-util/bpftool/bpftool-9999.ebuild | 121 +++++++++++++++++++++++++++++++++++ dev-util/bpftool/metadata.xml | 3 + 2 files changed, 124 insertions(+) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=90caa319c43d817ead57e02962189e79fb2089a3 commit 90caa319c43d817ead57e02962189e79fb2089a3 Author: Holger Hoffstätte <holger@applied-asynchrony.com> AuthorDate: 2024-10-23 13:20:11 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-10-30 22:28:53 +0000 dev-util/bpftool: add a sane 7.4.0 release This adds a proper 7.4.0 release (with some necessary patches sent upstream) built from the Github mirror instead of the previously used fragile kernel tree that produces unversioned 'mystery meat of the week'. This greatly simplifies the ebuild, makes generated code conform to well-defined ABI/API and no longer outputs misleading version information. Bug: https://bugs.gentoo.org/941248 Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com> Closes: https://github.com/gentoo/gentoo/pull/39088 Signed-off-by: Sam James <sam@gentoo.org> dev-util/bpftool/Manifest | 2 + dev-util/bpftool/bpftool-7.4.0.ebuild | 132 +++++++++++ ...ffs-on-provided-dir-instead-of-parent-dir.patch | 255 +++++++++++++++++++++ ...set-DESTDIR-to-empty-when-building-libbpf.patch | 38 +++ .../files/7.4-003-fix-typo-in-usage-help.patch | 30 +++ .../7.4-004-fix-the-wrong-format-specifier.patch | 38 +++ ...vior-caused-by-shifting-into-the-sign-bit.patch | 47 ++++ .../7.4-006-fix-undefined-behavior-in-qsort.patch | 49 ++++ ...t-build-time-when-trying-to-detect-libbfd.patch | 48 ++++ ...d-CLI-arguments-warning-for-feature-probe.patch | 38 +++ 10 files changed, 677 insertions(+)
