2022-01-20 11:07 UTC-0800 ~ Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx>
> 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.
Right, let's not tie it to libbpf either, having an independent
versioning scheme is probably the best solution indeed. I'll send a
patchset shortly to update the version and also print the one from libbpf.
Thanks,
Quentin
