Wrong src RPM deps parsing by rpmbuild #2690
Comments
|
Moreover, I don't understand how it appears in this srpm file. This file was made in our build scripts. |
|
The dependencies recorded in an src.rpm are only valid for the environment (including any cli-switches) it was generated in. It's entirely possible to end up with something quite different on a spec reparse, which is what happens on any build. As for pkg-config deps, I see this in the spec, which makes me wonder: I can't reproduce any pkgconfig deps appearing in the build, and I can't imagine rpm hallucinating them up either (this is certainly not AI 😅 ). I suggest you double check your findings. |
|
BTW, it's also technically possible to (externally) rewrite the specfile after launching a build on it, and end up with wildly different in the src.rpm than what the build was launched with. It would be a nasty thing to do of course, but technically possible, and could explain oddities like this when external build scripts are involved. |
|
@pmatilai Commented things – are my lines – I did not remove after experiments. Yes, our scripts build Yes, I have double-checked. And it is easily reproducible. We definitely DO NOT rewrite spec-file. We don't change .src.rpm file after it has been built. Tell me how to debug the issue. Yes, I understand it looks like some stupid and impossible thing, but I can not find the source of the problem. frr-8.5.2-2.1696412835.16.8ff8ce50.utm.src.zip Removed comments and built .src.rpm again. Everything is exactly the same. We build .src.rpm by this command: Anyway. |
|
The one thing -bs and -br will disagree with is dynamic buildrequires from %generate_buildrequires. I don't see that in the src.rpm but I don't know what macros and stuff you may have locally. |
|
I suggest you try reproducing it in a different environment. A clean container image or such. |
|
Oh, I see it now. Try 'rpmspec --parse frr.spec' to see how it looks to rpm, and it becomes quite clear. The pkgconf(systemd) dependency comes from the No bug here. |
|
@pmatilai sorry for bash script, but I want just show what happens in our build script: unpriv() {
su \
--login \
--whitelist-environment=OUR_DEBUG \
--shell=/usr/bin/env \
"$BUILD_USER" \
-- \
"PATH=$PATH" \
"HOME=/home/$BUILD_USER" \
"$@"
}
.....
unpriv rpmbuild "${defines[@]}" -bs "$spec_file" --rmspec
srpm=("$RPMBUILD"/SRPMS/*.src.rpm)
while :; do
unpriv rpmbuild "${defines[@]}" -rr "$srpm" && exit_code=0 || exit_code=$?
case "$exit_code" in
0)
break
;;
11)
reqsrpm=("$RPMBUILD"/SRPMS/*.buildreqs.nosrc.rpm)
if [ -f "$reqsrpm" ]; then
dnf -y builddep --srpm "$reqsrpm"
rm -f "$reqsrpm"
else
dnf -y builddep --srpm "$srpm" # <========= FALLS HERE because -rr DOES NOT generate.buildreqs.nosrc.rpm with "pkgconfig(systemd)"
fi
;;
*)
echo "rpmbuild -rr FAILED code $exit_code" >&2
exit 42
;;
esac
done
And on this package it falls into an endless loop. Note, environment is exactly the same on both rpmbuild runs. |
|
@pmatilai sorry for not explaining clearly. Seems there are two bugs.
|
|
Interesting... |
|
Rpm doesn't use the dependencies recorded into an src.rpm in any circumstance, the spec is always reparsed. I don't know what the difference between rpmbuild -bs and -br is in your environment, but that's where the issue is. |
|
@pmatilai there is no difference. Really. I have provided part of the shell script. Tell me how to debug, please. I strongly consider there is a bug in RPM, but can't knock it down. |
|
Seems I figured out. After installing deps from file generated by So the bug is: not generating |
|
Seems dup of #797 |
rpm -qRp /home/fedora/rpmbuild/SRPMS/frr-8.5.2-2.1696341206.16.8ff8ce50.utm.src.rpm:gives the following:
That's OK. Nothing about pkgconfig.
Now, try to build it:
rpmbuild --verbose --debug -rr /home/fedora/rpmbuild/SRPMS/frr-8.5.2-2.1696341206.16.8ff8ce50.utm.src.rpmSo, WHY? From one point of view it's not in dependencies, from another – it is.
RPM version 4.18.1
File is attached. Sorry for zip. GitHub does not allow attaching just rpm.
frr-8.5.2-2.1696341206.16.8ff8ce50.utm.src.zip
The text was updated successfully, but these errors were encountered: