https://bugzilla.redhat.com/show_bug.cgi?id=2184233 Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrii.nakryiko@xxxxxxxxx --- Comment #5 from Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> --- Hi Benson, I'm the author of veristat tool. I'll try to answer your questions. a) Regarding README, yep, it's definitely pretty bare and we should improve it. It used to be kernel-internal tool, so most of its documentation was contained in kernel commits. I did put links to it in Github README, but adding a bit more information and examples is on my TODO list. b) As for building from Github. I've been told that it's easier for packagers to have a dedicated mirror, which is what we do with libbpf and bpftool. So just following existing patterns. Another complication is that veristat in kernel repo is part of a BPF selftests, which is a very complicated setup with lots of dependencies and requirements that are not relevant to veristat itself, yet you'd have to satisfy nevertheless just because of selftests's Makefile organization. So I think it makes life easier for everyone to have Github mirror for veristat, where we ca, going forward, also maintain cleaner CHANGELOG, README, etc. c) Regarding libbpf-static. Lots of libbpf-using project do intentionally want to use specific libbpf version at exact commit, because libbpf is not a typical library and specific version (and sometimes even unreleased commit) is important. Beyond user-facing API, libbpf is a BPF loader, which processes complicated BPF object files and supports various features inside it (the list is too long to list, but it's like an entire runtime, which works tightly together with kernel). So it is important for applications to have a precise and tight control over exact libbpf commit to be used. So tl;dr, it's best to use exact libbpf version as archived during veristat release. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2184233 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
