On Sat, 2023-12-02 at 20:04 +0000, Sudip Mukherjee wrote: > Package: bpftool > Severity: wishlist > X-Debbugs-Cc: sudipm.mukherjee@gmail.com, debian-kernel@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. I don't really understand the distinction they're trying to make between "official" and "authoritative"... > 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. That's certainly a good reason. > 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, So bpftool does not get stabilised in the kernel? I don't really understand why it's still in the kernel tree at all then! > 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. Right. > 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. Since you are already maintaining libbpf I would be happy to hand over bpftool to you. I will try to discuss this at this evening's team meeting. Ben. > > [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-78afbf6fc325@isovalent.com/ > -- Ben Hutchings Always try to do things in chronological order; it's less confusing that way.
Attachment:
signature.asc
Description: This is a digitally signed message part