Package: bpftool Severity: wishlist X-Debbugs-Cc: sudipm.mukher...@gmail.com, debian-ker...@lists.debian.org, debian-devel@lists.debian.org
The official home for bpftool is now the github repo [1] but keeps the kernel as the authoritative source code of bpftool and is developed as part of the bpf-next Linux source tree. The Maintainers have said "Please use this Github repository for building and packaging bpftool" at [2] The announcement was at [3]. imho, packaging it from the github instead of the kernel source will fix three issues: 1. bpftool will use libbpf available in Debian, whereas now it is building a libbpf.a from the development codes of libbpf in the kernel source and using that. 2. The official releases of bpftool is done in the github repo when the bpf maintainers decides the code is ready for a release. But the Debian bpftool package is done from the kernel source and so follows the kernel releases. And as a result, when a new kernel is released which Debian kernel team will then pickup may not have a bpftool release worthy code. For example, bpftool v7.3 was released on 23/11/2023, 3. bpftool package in Debian is from the kernel v6.5.13 and so looking at the source and git commits I can see the that the Debian package is missing 25 commits which is in the bpftool v7.3 release. Do we package bpftool from their github repo independent of the kernel update? Then we will need to remove the bpftool building bits from the Debian kernel source and create a separate package for bpftool. And so, it will be great if kernel team will like to package and maintain it, if not, then I will be happy to do it. Please reject this bug report if you think bpftool should not be done separately and should live inside kernel source package. [1]. https://github.com/libbpf/bpftool [2]. https://github.com/libbpf/bpftool/blob/main/README.md?plain=1#L18 [3]. https://lore.kernel.org/bpf/267a35a6-a045-c025-c2d9-78afbf6fc...@isovalent.com/ -- Regards Sudip
