Re: Packaging bpftool and libbpf: GitHub or kernel?

["Michal Suchánek" <msuchanek@suse.de>]

Hello,

On Fri, Apr 14, 2023 at 02:12:40AM +0100, Quentin Monnet wrote:
> On Thu, 13 Apr 2023 at 10:50, Shung-Hsi Yu <shung-hsi.yu@suse.com> wrote:
> >
> > On Thu, Apr 13, 2023 at 05:23:16PM +0800, Shung-Hsi Yu 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?

...

> > But I wonder whether packaging one of the motives to create the mirrors
> > initially? Can't seem to find anything in this regard.
> >
> >
> > 1: https://github.com/acmel/dwarves/tree/master/lib
> > 2: https://lore.kernel.org/bpf/CAEf4BzZ+0XpH_zJ0P78vjzmFAH3kGZ21w3-LcSEG=B=+ZQWJ=w@mail.gmail.com/
> 
> It seems like you haven't come across this one?:
> https://lore.kernel.org/bpf/267a35a6-a045-c025-c2d9-78afbf6fc325@isovalent.com/t/
> 
> Yes, easing packaging was one of the motivations for the mirror. As
> mentioned in my other answer, I've not taken the time to reach out to
> package maintainers yet, so this hasn't really materialised at this
> point.

For me as a package maintainer submodules are a major pain. They always
need special handling, break down, get out of sync between different
projects using them, etc.

Somehow in the past it was possible to build and install development
versions of libraries during development of tools using them, and
release both when a feature was finished.

Arguably using submodules for development may work for some people. For
most it would cause having the wrong submodule code when switching
branches, stray submodule changes in patches, etc.

Using submodules as a general method of distributing dependencies is
hell.

The usual methods of downloading and releasing the source code don't
work, the submodules have to be specifically bundled.

If the dependency in question has a bug each tool author has to be
coaxed to update to a fixed version and re-release, or each tool patched
separately.

Over time API bitrots and is given up, each tool requiring specific and
different release or git SHA of the dependency. We can see that
happening a lot in ecosystems where vendoring is the norm.

Thanks

Michal