I cannot mock-rebuild packages that have /some/ BuildRequires: with explicit file dependencies, for F40. I have no idea why just /some/ of them are rejected.
I'm using mock to rebuild SRPMS in an F40 chroot, and it fails thusly:
Updating and loading repositories: updates 100% | 286.7 KiB/s | 23.8 KiB | 00m00s fedora 100% | 229.3 KiB/s | 19.7 KiB | 00m00s Repositories loaded. Failed to resolve the transaction: No match for argument: /usr/include/ltdl.h No match for argument: /usr/lib/rpm/macros.d/macros.systemd
These are absolute file paths referenced by BuildRequires:.
I replaced the problematic BuildRequires: with package names, libtool-ltdl- devel and systemd-rpm-macros. This allowed the build to proceed.
But here's a head-scratcher. Here's (a part of) my diff:
--- a/courier-authlib/courier-authlib.spec.in +++ b/courier-authlib/courier-authlib.spec.in @@ -54,7 +54,7 @@ BuildRequires: redhat-rpm-config BuildRequires: courier-unicode-devel BuildRequires: %{__make} BuildRequires: shadow-utils -BuildRequires: %{_includedir}/ltdl.h +BuildRequires: libtool-ltdl-devel
That %{__make} is still there. Somewhat unneeded, but it's there. And this built fine.
So, can anyone tell me why %{_includedir}/ltdl.h, which is /usr/include/ltdl.h, got rejected by mock+dnf5, but %{__make}, which is /usr/bin/make was just peachy?
Sam Varshavchik wrote:
I cannot mock-rebuild packages that have /some/ BuildRequires: with explicit file dependencies, for F40. I have no idea why just /some/ of them are rejected.
I'm using mock to rebuild SRPMS in an F40 chroot, and it fails thusly:
Updating and loading repositories: updates 100% | 286.7 KiB/s | 23.8 KiB | 00m00s fedora 100% | 229.3 KiB/s | 19.7 KiB | 00m00s Repositories loaded. Failed to resolve the transaction: No match for argument: /usr/include/ltdl.h No match for argument: /usr/lib/rpm/macros.d/macros.systemd
These are absolute file paths referenced by BuildRequires:.
I replaced the problematic BuildRequires: with package names, libtool-ltdl-devel and systemd-rpm-macros. This allowed the build to proceed.
But here's a head-scratcher. Here's (a part of) my diff:
--- a/courier-authlib/courier-authlib.spec.in +++ b/courier-authlib/courier-authlib.spec.in @@ -54,7 +54,7 @@ BuildRequires: redhat-rpm-config BuildRequires: courier-unicode-devel BuildRequires: %{__make} BuildRequires: shadow-utils -BuildRequires: %{_includedir}/ltdl.h +BuildRequires: libtool-ltdl-devel
That %{__make} is still there. Somewhat unneeded, but it's there. And this built fine.
So, can anyone tell me why %{_includedir}/ltdl.h, which is /usr/include/ltdl.h, got rejected by mock+dnf5, but %{__make}, which is /usr/bin/make was just peachy?
Using file or directory paths in requires is only allowed for /usr/bin /usr/sbin, and /etc, per the packaging guidelines¹.
I didn't dig through the dnf5 changes for a link, but I believe that it doesn't support such out-of-scope path dependencies like /usr/include.
Additionally, using installation path macros aren't allowed anymore:
When declaring file and directory dependencies, installation path macros like %{_bindir} MUST NOT be used. %{_bindir} of the package that provides sometool may be different from %{_bindir} of a package that requires sometool. In such case, BuildRequires: %{_bindir}/sometool does not work as expected.
That's not relevant to this specific case, but it's a close tangent and seemed worth mentioning.
¹ https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directo...
Todd Zullinger writes:
So, can anyone tell me why %{_includedir}/ltdl.h, which is /usr/include/ltdl.h, got rejected by mock+dnf5, but %{__make}, which is /usr/bin/make was just peachy?
Using file or directory paths in requires is only allowed for /usr/bin /usr/sbin, and /etc, per the packaging guidelines¹.
I didn't dig through the dnf5 changes for a link, but I believe that it doesn't support such out-of-scope path dependencies like /usr/include.
The odd thing is that dnf5 repoquery works for any path. I just checked, and it told me which package provides /usr/include/ltdl.h
This may very well be a packaging guideline for Fedora, but I would think that rmplint would be the one complaining. mock must be attempting to resolve this dependency on its own, because if it's up to dnf5 it wouldn't have any problems with it. I wonder what rpmbuild in F40 will say, here…
-
Sam Varshavchik -
Todd Zullinger