LLVM version pinning in spec file
Hi, I'm trying to figure out the most ideal way to pin the dependency on LLVM so specific version is used for bcc and bpftrace. For context, we have several different LLVM and Clang versions in Factory, e.g. llvm17-devel and llvm18-devel coexists, while the unversioned llvm-devel is a just a package that simply requires llvm$LATEST-devel. Version pinning is required because it is expected that LLVM major version upgrade will have breaking API changes, and it takes a while before the depending packages adapt. Right now I'm using the suggestion in SR#1134405, aligning to PostgreSQL's approach (product_libs_llvm_ver is defined in project config to the latest major LLVM version): %if 0%{?product_libs_llvm_ver} > 17 %define llvm_major_version 17 %else %define llvm_major_version %{nil} %endif ... BuildRequires: llvm%{llvm_major_version}-devel But I ran into unresolvable build for bpftrace[1] on OBS with the error message: conflict for providers of llvm-devel needed by bcc-devel, (provider llvm-devel obsoletes llvm17-devel) I'm guessing this comes from the following dependency tree: bpftrace --> llvm17-devel (product_libs_llvm_ver is 18) | +------> bcc-devel -----> llvm-devel[2] (back when product_libs_llvm_ver was 17?) So it seems like for Factory, even when building against the unversioned llvm packages I'd still need to pin the version with BuildRequires: llvm-devel = %{product_libs_llvm_ver} Or just not use the unversioned on at all, replacing %{nil} with %{product_libs_llvm_ver}. %if 0%{?product_libs_llvm_ver} > 17 %define llvm_major_version 17 %else %define llvm_major_version %{product_libs_llvm_ver} %endif ... BuildRequires: llvm%{llvm_major_version}-devel I'm a bit unsure whether I reasoned the unresolvable build message correctly though. Suggestion and feedbacks are all welcome. Thanks, Shung-Hsi Yu 1: https://build.opensuse.org/package/show/devel:tools/bpftrace 2: Saw this dependency openSUSE:Factory/bcc $ rpm -q --requires bcc-devel-0.29.1-3.1 /usr/bin/pkg-config libbcc0 = 0.29.1 llvm-devel rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1
Am 19.03.24 um 08:11 schrieb Shung-Hsi Yu:
Right now I'm using the suggestion in SR#1134405, aligning to PostgreSQL's approach (product_libs_llvm_ver is defined in project config to the latest major LLVM version):
%if 0%{?product_libs_llvm_ver} > 17 %define llvm_major_version 17 %else %define llvm_major_version %{nil} %endif ... BuildRequires: llvm%{llvm_major_version}-devel The advantage of this approach is that you get the newest version that is (a) contained in the distribution and (b) supported by the package. On Tumbleweed, the package is typically the limiting factor, but on Leap you might actually support a newer LLVM than what is available. This will just select the highest version available then. But I ran into unresolvable build for bpftrace[1] on OBS with the error message:
conflict for providers of llvm-devel needed by bcc-devel, (provider llvm-devel obsoletes llvm17-devel)
I'm guessing this comes from the following dependency tree:
bpftrace --> llvm17-devel (product_libs_llvm_ver is 18) | +------> bcc-devel -----> llvm-devel[2] (back when product_libs_llvm_ver was 17?)
You should probably only use llvm-devel for BuildRequires, and then add Requires corresponding to the version it was built with. The best way to do it would probably be BuildRequires: llvm%{llvm_major_version}-devel Requires: llvm%{_llvm_sonum}-devel This uses the macro defined in %{_rpmconfigdir}/macros.d/macros.llvm, which is part of llvmX-devel. By writing it like that, the package gets a requirement to the LLVM version it was built with, ensuring ABI compatibility. Best regards, Aaron
On Wed, Mar 20, 2024 at 03:02:03AM +0100, Aaron Puchert wrote:
Am 19.03.24 um 08:11 schrieb Shung-Hsi Yu:
Right now I'm using the suggestion in SR#1134405, aligning to PostgreSQL's approach (product_libs_llvm_ver is defined in project config to the latest major LLVM version):
%if 0%{?product_libs_llvm_ver} > 17 %define llvm_major_version 17 %else %define llvm_major_version %{nil} %endif ... BuildRequires: llvm%{llvm_major_version}-devel The advantage of this approach is that you get the newest version that is (a) contained in the distribution and (b) supported by the package. On Tumbleweed, the package is typically the limiting factor, but on Leap you might actually support a newer LLVM than what is available. This will just select the highest version available then. But I ran into unresolvable build for bpftrace[1] on OBS with the error message:
conflict for providers of llvm-devel needed by bcc-devel, (provider llvm-devel obsoletes llvm17-devel)
I'm guessing this comes from the following dependency tree:
bpftrace --> llvm17-devel (product_libs_llvm_ver is 18) | +------> bcc-devel -----> llvm-devel[2] (back when product_libs_llvm_ver was 17?)
You should probably only use llvm-devel for BuildRequires, and then add Requires corresponding to the version it was built with. The best way to do it would probably be
BuildRequires: llvm%{llvm_major_version}-devel Requires: llvm%{_llvm_sonum}-devel
This uses the macro defined in %{_rpmconfigdir}/macros.d/macros.llvm, which is part of llvmX-devel. By writing it like that, the package gets a requirement to the LLVM version it was built with, ensuring ABI compatibility.
Thanks for the reply! So if I understand everything correctly, this is likely related to bcc's recent change in SR1152316 that ended up affecting bpftrace: %package devel Summary: Header files for the BPF Compiler Collection Group: Development/Languages/C and C++ Requires: libbcc0 = %{version} +Requires: llvm%{llvm_major_version}-devel And I should just need to update bcc-devel with the following change %package devel ... -Requires: llvm%{llvm_major_version}-devel +Requires: llvm%{_llvm_sonum}-devel Does that sound right? Thanks, Shung-Hsi
Am 22.03.24 um 12:16 schrieb Shung-Hsi Yu:
Am 19.03.24 um 08:11 schrieb Shung-Hsi Yu:
Right now I'm using the suggestion in SR#1134405, aligning to PostgreSQL's approach (product_libs_llvm_ver is defined in project config to the latest major LLVM version):
%if 0%{?product_libs_llvm_ver} > 17 %define llvm_major_version 17 %else %define llvm_major_version %{nil} %endif ... BuildRequires: llvm%{llvm_major_version}-devel The advantage of this approach is that you get the newest version that is (a) contained in the distribution and (b) supported by the package. On Tumbleweed, the package is typically the limiting factor, but on Leap you might actually support a newer LLVM than what is available. This will just select the highest version available then. But I ran into unresolvable build for bpftrace[1] on OBS with the error message:
conflict for providers of llvm-devel needed by bcc-devel, (provider llvm-devel obsoletes llvm17-devel)
I'm guessing this comes from the following dependency tree:
bpftrace --> llvm17-devel (product_libs_llvm_ver is 18) | +------> bcc-devel -----> llvm-devel[2] (back when product_libs_llvm_ver was 17?) You should probably only use llvm-devel for BuildRequires, and then add Requires corresponding to the version it was built with. The best way to do it would probably be
BuildRequires: llvm%{llvm_major_version}-devel Requires: llvm%{_llvm_sonum}-devel
This uses the macro defined in %{_rpmconfigdir}/macros.d/macros.llvm, which is part of llvmX-devel. By writing it like that, the package gets a requirement to the LLVM version it was built with, ensuring ABI compatibility. Thanks for the reply! So if I understand everything correctly, this is
On Wed, Mar 20, 2024 at 03:02:03AM +0100, Aaron Puchert wrote: likely related to bcc's recent change in SR1152316 that ended up affecting bpftrace:
%package devel Summary: Header files for the BPF Compiler Collection Group: Development/Languages/C and C++ Requires: libbcc0 = %{version} +Requires: llvm%{llvm_major_version}-devel
And I should just need to update bcc-devel with the following change
%package devel ... -Requires: llvm%{llvm_major_version}-devel +Requires: llvm%{_llvm_sonum}-devel
Does that sound right?
Yes, that sounds right. It should require the version of LLVM the package was built with, not whatever the metapackage points to, which might already be a different version when the package is installed. Best regards, Aaron
participants (2)
-
Aaron Puchert
-
Shung-Hsi Yu