retitle 948041 libbpf-dev: please build from https://github.com/libbpf/libbpf reassign 948041 libbpf-dev merge 942903 948041 quit
Hi, Julia Kartseva wrote: > On Sun, 12 Jan 2020 09:51:55 +0100 Bastian Blank <wa...@debian.org> wrote: >> Why should we? If the upstream developers decide to maintain it >> independently, aka don't use the kernel repo as true source, or better, >> remove the source from it, then we have something to do. I agree --- if upstream development were happening in https://github.com/libbpf/libbpf then this would be a no-brainer. It appears to instead be a mirror of the source that's in the kernel repo, though. > Why should we switch from kernel sources to GH is a frequently asked > question so the reason was explained in libbpf README [1]. If I'm reading that correctly, the intent appears to be that it would allow faster libbpf upgrades. In the context of the Debian project, that could go both ways. The Linux kernel packages are very well maintained. New versions appear in stable-backports pretty quickly, and that's *less* likely to happen with a separate libbpf source package. Binary package dependencies do not force an end user to use the same version of the kernel as userspace tools like this one. Debian even permits binary packages to have different version numbers from the source package they were built from. Depending packages would likely use Debian's shlibs or symbols mechanism (if upstream provides symbol versioning, that is very helpful) to automatically produce appropriate dependencies. More details about this are at https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#dependencies-between-the-library-and-other-packages So this appears to impose exactly the same costs and benefits as any other instance where someone splits a binary package that comes from the same upstream source package into a separate Debian source package. Sometimes that is the right thing to do, especially when the Debian maintainers for the two packages do not work very closely together. Is that the case here? Is there some underlying need that we could address more directly? I think I'm missing some piece of the motivation here. Thanks, Jonathan > [1] https://github.com/libbpf/libbpf#distributions