On 03/25/2019 01:21 PM, Jiri Olsa wrote:
> hi guys,
> we want to package libbpf and I'd like to coordinate
> with you on some issues I've met on this:
>
> 1) I think libbpf should be part of kernel-tools-libs and kernel-tools-libs-devel,
> which would look like below (from early rpm build):
>
> $ rpm -qpl kernel-tools-libs-5.0.0-1.fc31.x86_64.rpm
> /usr/lib/.build-id
> /usr/lib/.build-id/ca
> /usr/lib/.build-id/ca/654da1e5ea553f985e28b8d98ad24e51f19e88
> /usr/lib/.build-id/f6
> /usr/lib/.build-id/f6/a788b316f26fbe70db47bfc0ef500348117023
> /usr/lib64/libbpf.so.0
> /usr/lib64/libbpf.so.0.0.1
> /usr/lib64/libcpupower.so.0
> /usr/lib64/libcpupower.so.0.0.1
> /usr/share/licenses/kernel-tools-libs
> /usr/share/licenses/kernel-tools-libs/COPYING
>
> $ rpm -qpl kernel-tools-libs-devel-5.0.0-1.fc31.x86_64.rpm
> /usr/include/bpf/bpf.h
> /usr/include/bpf/btf.h
> /usr/include/bpf/libbpf.h
> /usr/include/cpufreq.h
> /usr/include/cpuidle.h
> /usr/lib64/libbpf.a
> /usr/lib64/libbpf.so
> /usr/lib64/libcpupower.so
>
> Do you see libbpf as a standalone package or kernel-tools-libs* wuold be ok for you?
My preference is definitely on making libbpf a stand-alone package, so
people can just install 'libbpf' or 'libbpf-dev{,el}' and are good to
go. Also given the pace it's growing these days, it absolutely qualifies
as a stand-alone package.
> 2) There's already bcc-devel's libbpf library packaged:
>
> $ rpm -qf /usr/lib64/libbpf.so
> bcc-devel-0.8.0-1.fc28.x86_64
>
> so there's a conflict.. any chance we could rename libbpf to
> something else like:
>
> libbpf2.so
> libbpfobject.so
> libbpfbest.so
> ...?
I don't think we should rename the official libbpf package, this will
just create plain confusion and will make it much harder for potential
users to adapt in the long-term since we aim for /everyone/ to consume
official libbpf library instead of hacking their own.
I think bcc folks are migrating to official libbpf as well, at least
that was my impression. Imho, this would need fixing on bcc side then.
> I checked and I think those 2 conflicting libraries don't make
> a valid case for using 'alternatives'.
>
> Also the libbpf.so from bcc-devel has been there for some time
> so we can't just remove/rename it.. ;-)
> thoughts?
>
>
> thanks,
> jirka
>
