On Tue, Apr 18, 2023 at 10:41 AM Michal Suchánek <msuchanek@xxxxxxx> wrote: > > On Tue, Apr 18, 2023 at 09:38:20AM -0700, Andrii Nakryiko wrote: > > On Tue, Apr 18, 2023 at 4:24 AM Michal Suchánek <msuchanek@xxxxxxx> wrote: > > > > > > On Mon, Apr 17, 2023 at 05:20:03PM -0700, Andrii Nakryiko wrote: > > > > On Fri, Apr 14, 2023 at 9:15 AM Michal Suchánek <msuchanek@xxxxxxx> wrote: > > > > > > > > > > On Fri, Apr 14, 2023 at 01:30:02PM +0100, Quentin Monnet wrote: > > > > > > 2023-04-14 11:50 UTC+0200 ~ Michal Suchánek <msuchanek@xxxxxxx> > > > > > > > Hello, > > > > > > > > > > > > > > On Fri, Apr 14, 2023 at 01:35:20AM +0100, Quentin Monnet wrote: > > > > > > >> Hi Shung-Hsi, > > > > > > >> > > > > > > >> On Thu, 13 Apr 2023 at 10:23, Shung-Hsi Yu <shung-hsi.yu@xxxxxxxx> wrote: > > > > > > >>> > > > > > > >>> Hi, > > > > > > >>> > > > > > > >>> I'm considering switch to bpftool's mirror on GitHub for packaging (instead > > > > > > >>> of using the source found in kernel), but realize that it should goes > > > > > > >>> hand-in-hand with how libbpf is packaged, which eventually leads these > > > > > > >>> questions: > > > > > > >>> > > > > > > >>> What is the suggested approach for packaging bpftool and libbpf? > > > > > > >>> Which source is preferred, GitHub or kernel? > > > > > > >> > > > > > > >> As you can see from the previous discussions, the suggested approach > > > > > > >> would be to package from the GitHub mirror, with libbpf and bpftool in > > > > > > >> sync. > > > > > > >> > > > > > > >> My main argument for the mirror is that it keeps things simpler, and > > > > > > >> there's no need to deal with the rest of the kernel sources for these > > > > > > >> packages. Download from the mirrors, build, ship. But then I have > > > > > > >> limited experience at packaging for distros, and I can understand > > > > > > >> Toke's point of view, too. So ultimately, the call is yours. > > > > > > > > > > > > > > Things get only ever more complex when submodules are involved. > > > > > > > > > > > > I understand the generic pain points from your other email. But could > > > > > > you be more specific for the case of bpftool? It's not like we're > > > > > > shipping all lib dependencies as submodules. Sync-ups are specifically > > > > > > aligned to the same commit used to sync the libbpf mirror, so that it's > > > > > > pretty much as if we had the right version of the library shipped in the > > > > > > repository - only, it's one --recurse-submodules away. > > > > > > > > > > It's so in every project that uses submodules. Except git does not > > > > > recurse into submodules by default, you have to fix it up by hand. > > > > > Forges don't support submodules so you will not get the submodule when > > > > > downloading the project archive, and won't see it the the project tree. > > > > > > > > git submodule update --init --recursive didn't work? > > > > > > That's one part of the manual fixup. > > > > > > The other part is after each git operation that could possibly cause the > > > submodules to go out of sync, basically any operation that changes the > > > checked-out commit. > > > > > > Of course, you can make some shell aliases that append whatever submodule > > > chicanery to whatever git command you might issue, and tell everyone > > > else to do that, and then it will work in that one shell, and not in any > > > other shell nor any tool that invokes git directly. > > > > Are we discussing a *standard* Git submodule feature and argue that > > because it might be cumbersome or unfamiliar to some engineers that > > projects should avoid using Git submodules? > > As far as I am aware they are unfamiliar to *most* engineers, and for > good reasons. > > > For one, I don't have any special aliases for dealing with Git > > submodules and it works fine. If I jump between branches or tags which > > update Git submodule reference, I do above `git submodule update > > --init --recursive` explicitly if I see that Git status shows > > out-of-sync Git submodule state. If I want to update a Git submodule, > > I update the submodule's Git repo, and then git add it in the repo > > that uses this submodule. I haven't run into any other issues with > > this. > > You know, git could just handle submodules automagically. As you say, > it's not rocket science. For historical reasons it does not. > > With that working with submodules is cumbersome, and it's additional > thing that can break down that the engineer needs to be constantly aware > of increasing the mental overhead of working with such projects. > > It may not be much of a problem for people who work with such projects > daily but not everyone does. Those who don't need to do the mental > switch whenever submodules are encountered, and are prone to getting > issues when they forget that they have to go that extra mile for this > specific project. I agree with you that Git submodules are not the most straightforward feature usability-wise. Where I disagree is that this is enough reason to not use Git submodules. They do provide a lot of value. > > > > > > After previous experience with submodules I did not even try, I just > > > > > patched the makefile to use system libbpf before attempting anything > > > > > else. > > > > > > > > Quentin mentioned that he's packaging (or will package) libbpf sources > > > > as part of bpftool release on Github. I've been this for other > > > > libbpf-using tools as well, and it works pretty well (at least for > > > > Fedora and ArchLinux). E.g., srcs-full-* archives for veristat ([0]) > > > > > > > > By switching up actual libbpf used to compile with bpftool, you are > > > > potentially introducing subtle problems that your users will be quite > > > > unhappy about, if they run into them. Let's work together to make it > > > > easier for you to package bpftool properly. We can't switch bpftool to > > > > reliably use system-wide libbpf (either static or shared, doesn't > > > > matter) because of dependency on internal functionality. > > > > > > > > > > > > [0] https://github.com/libbpf/veristat/releases/tag/v0.1 > > > > > > So how many copies of libbpf do I need for having a CO-RE toolchain? > > > > What do you mean by "CO-RE toolchain"? bpftool, veristat, retsnoop, > > etc are tools. The fact they are using statically linked libbpf > > through Git submodule is irrelevant to end users. You need one libbpf > > in the system (for those who link dynamically against libbpf), the > > rest are just tools. > > > > > > > > Will different tools have different view of the kernel because they each > > > use different private copy of libbpf with different features? > > > > That's up to tools, not libbpf. You are over pivoting on libbpf here. > > There is one view of the kernel, it depends on what features the > > kernel supports. If the tool requires some specific functionality of > > libbpf, it will update its Git submodule reference to get a version of > > libbpf that provides that feature. That's the point, an > > application/tool is in control of what kind of features it gets from > > libbpf. > > > > > > > > When there is a bug in libbpf how many places need to be patched to fix > > > it? > > > > That's up to tools, again. If the bug is affecting them, they should > > cut a new version of their *tool*, using a patched version of libbpf > > from Github. If it doesn't affect them, then it doesn't matter *to > > them*. > > I don't share your optimism about this happening in the real world. > > For one the issue that the github tarballs do not contain the submodule > and thus cannot be built was raised nearly two months ago, and while a > test snapshot that does include the submodule is released, a release > does not exist yet. Because no one raised this issue earlier (for bpftool). Fedora packagers raised it for retsnoop, so retsnoop has it. That's how development works, one can't anticipate all the possible issues, they need to be reported and worked on. > > For people to make use of the repository without a release cut they need > to replicate that submodule support - that is add support for submodules > in their development tooling. Otherwise you personally cutting a release > becomes a single point of failure. I hope distros won't be packaging an unreleased version, though? > > Because there is no API it's not really advisable to just apply patches > on top of the last release either. Applying patches may cause the main > project and the submodule to go out of sync, the submodule would not get > updated by applying a patch to the main project, and the other way > around. I'm not sure where we are going with this overall discussion at this point, tbh. > > Suppose a severe security bug that requires patching libbpf is found. > Now there is a number of tools that are each tied to one specific > version of libbpf, and cannot be upgraded to up-to-date fixed version > because that would break them. I would hope that never happens. > Nonetheless, libbpf is used to generate code, and if the code is > generated wrong worst case it can have severe security implications. > Yes, I hear this argument from packagers all the time. Yet, somehow it's been fine for the last few years. Please realize that there are many reasons why we do want submodules and static linking of libbpf, and accept that projects do decide to stick to submodules. It might not be perfect, but the benefits of such an approach outweigh the hypothetical issues you brought up. This has all been discussed multiple times, as I said, I don't think any of us added anything new to previous discussions. So if you are interested, please work with us to improve your life as a packager, but also accept the way this project is set up on Github. > Thanks > > Michal
