On Fri, Nov 1, 2019 at 2:41 PM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: > > >> The only concern with this is that without a flow of bugfixes into the > >> 'bpf' tree (and stable), users may end up with buggy versions of libbpf. > >> Which is in no one's interest. So how do we avoid that? > > > > As I explained earlier. There is no 'bpf' tree for libbpf. It always > > moves forward. > > Yes, you did. And I was just pointing out that this means that there > will be no bug fixes in older versions. So the only way to update is to > move to an entirely new version of libbpf, including updating all the > headers in /usr/include. And when that is not feasible, then the only > choice left is to ship a buggy libbpf... Unless you have a third option > I'm missing? I'm not seeing the problem still. Say there is a bug in installed libbpf package. A bunch of services are using it as libbpf.so The admin upgrades libbpf package. New libbpf.so is installed and services should continue work as-is, since we're preserving api binary compatibility. Now if you're a developer you install libbpf-devel and the first thing you'll hit is that /usr/include is so old that it doesn't have basic things to start writing bpf progs. So recent linux-api-headers package would have to be installed. You keep developing stuff. Few month passes by. New libbpf is released. At the current pace of the development one release contains a bunch of features and a bunch of fixes. If you're upgrading it you'd need to refresh api-headers too. So where is the problem? Of course there is an option to branch existing libbpf releases, but let's cross that bridge when we actually need to do that.
