Open dmnks opened 3 months ago
Thinking about it again, the word "sane" perhaps isn't entirely right, this actually isn't desired :smile: Even though we don't claim for $RPM_BUILD_ROOT
to be an absolute path, it kinda makes sense for it to be, or we shouldn't at least regress here...
Just for completeness, this issue was found thanks to the following test: https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/tests/auto-set-build-flags/runtest.sh
We never supported relative %_builddir and whatnot, that they happened to work in some cases was more like a lucky incident.
Ack, in that case, let's just close (we can always include a note in the RN).
Let's leave it open for a bit, we might want to make an explicit check for absolute path instead.
If
%_builddir
is a relative path configured externally (e.g..
), when we internally override it with the newly created per-package subdirectory, it's still a relative path (e.g../test-1-build
). That, in turn, ends up in$RPM_BUILD_ROOT
at build scriptlet execution time which is initialized from the new%_builddir
.This is of course sane but it happens to break the expectation of at least one macro config which we ship in Fedora via redhat-rpm-config, namely:
As a result, when you build a package with such a relative builddir set, another subdirectory will be created in the
%install
stage andcd
ed into which breaks the rest of the script.As mentioned, this is not necessarily a bug per se, however it may result in random breakage wherever relative paths are configured in
%_builddir
.If we don't choose to fix this, we might want to at least add a compatibility note to the 4.20 release notes.