Re: Packaging bpftool and libbpf: GitHub or kernel?

[Andrii Nakryiko <andrii.nakryiko@gmail.com>]

On Fri, Apr 28, 2023 at 2:13 AM Shung-Hsi Yu <shung-hsi.yu@suse.com> wrote:
>
> On Thu, Apr 20, 2023 at 02:39:17PM -0700, Andrii Nakryiko wrote:
> > On Thu, Apr 20, 2023 at 7:46 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
> > > [snip]
> > > Right, well, you don't *have* to be cooperative with the wider
> > > ecosystem, of course. Just as packagers don't have to follow your
> > > recommendations if they have good reasons not to. I believe we've had
> > > this discussion before, and I don't think we're going to agree this time
> > > around either, so let's not waste any more virtual ink on rehashing it :)
> >
> > Exactly, so I'm not sure why we are even having this conversation all
> > over again. I agree on not wasting virtual ink anymore. I'm not
> > forcing anyone to follow my advice, I expect others to not force me to
> > follow theirs.
>
> Thanks for still going through the reasoning.
>
> I don't have anything to add to the discussion, so instead here's an attempt
> to summarize the thread thus far, reading between the lines here and there
> to keep it terse but complete; feel free to point out where I misunderstood.
>
>
> # Packaging bpftool and libbpf
>
> - bpftool and libbpf version should be kept in sync
>   - interdependency is by design
>   - bpftool uses private functionality of libbpf
>   - bpftool generated file is tie to specific libbpf (?)

this bullet point is not true, generated BPF skeleton or statically
linked BPF object file should work across wide range of libbpf
versions

>
> - the GitHub mirror is the recommended source
>
> - benefits of using the GitHub mirror includes
>   - ease of upgrade
>   - maintainer crafted changelog

I'd also say consistency between all distros (assuming everyone use
Github mirror). Because release X means exactly the same set of
commits.

>
> - downsides of using the GitHub mirror has to do with kernel backporting
>
> - git submodule requires extra work for distros to package
>   - offsetted if the source of submodules are released along
>
> - bpftool releases will (have a file that) includes submodules' source along
>   going forward
>
> - bpftool and libbpf both should work on earlier kernel (if not it's a bug)
>
>
> # Other
>
> - motivations for GitHub mirror
>   - ease of distribution, packaging, build
>   - CI, to be used as submodule, Window support, etc.
>
> - libbpf interface stability
>   - stable API and ABI (within major version)
>   - BPF object format is not considered stable

BPF object file format is stable, but not frozen, it can keep evolving

>
> - libbpf is not opinionated in how it's used as a library, either
>   - statically or dynamically linked
>   - a tagged release or a random commit
>
> - on statically linking libbpf
>   - reasoning
>     - full control of implementation detail, decouples from distro package
>   - against
>     - difficulty in applying fixes
>

Looks good to me apart from things I pointed out above. Thanks for summarizing!


>
> Shung-Hsi
>
> > >
> > > -Toke
> > >