On Thu, Jan 20, 2022 at 4:35 AM Quentin Monnet <quentin@xxxxxxxxxxxxx> wrote:
>
> 2022-01-19 22:25 UTC-0800 ~ Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx>
> > On Wed, Jan 19, 2022 at 6:47 AM Quentin Monnet <quentin@xxxxxxxxxxxxx> wrote:
>
> [...]
>
> >> 2. Because it is easier to compile and ship, this mirror should
> >> hopefully simplify bpftool packaging for distributions.
> >
> > Right, I hope disto packagers will be quick to adopt the new mirror
> > repo for packaging bpftool. Let's figure out bpftool versioning schema
> > as a next step. Given bpftool heavily relies on libbpf and isn't
> > really coupled to kernel versions, it makes sense for bpftool to
> > reflect libbpf version rather than kernel's. WDYT?
>
> Personally, I don't mind finding another scheme, as long as we keep it
> consistent between the reference sources in the kernel repo and the mirror.
>
> I also agree that it would make sense to align it to libbpf, but that
> would mean going backward on the numbers (current version is 5.16.0,
> libbpf's is 0.7.0) and this will mess up with every script trying to
> compare versions. We could maybe add a prefix to indicate that the
> scheme has changed ('l_0.7.0), but similarly, it would break a good
> number of tools that expect semantic versioning, I don't think this is
> any better.
>
> The other alternative I see would be to pick a different major version
> number and arbitrarily declare that bpftool's version is aligned on
> libbpf's, but with a difference of 6 for the version number. So we would
> start at 6.7.0 and reach 7.0.0 when libbpf 1.0.0 is released. This is
> not ideal, but we would keep some consistency, and we can always add the
> version of libbpf used for the build to "bpftool version"'s output. How
> would you feel about it? Did you have something else in mind?
Yeah, this off-by-6 major version difference seems ok-ish to me, I
don't mind that. Another alternative is to have a completely
independent versioning (and report used libbpf version in bpftool
--version output separately). But I think divorcing it from kernel
version is a must, too much confusion.
>
> Quentin
