[Rpm-maint] [rpm-software-management/rpm] Make --build-in-place much less of a hack and also, work (PR #3124)

[Panu Matilainen]

Instead of skipping everything in %setup, take advantage of it: we shouldn't unpack any sources but otherwise we can just let it fall through it, defining buildsubdir and everything, if we let rpm do its normal %mkbuilddir thing and just symlink to the in-place tree from rpm's %builddir. This way it's not such an ugly duckling interfering with how normal rpms are built, and even honors %setup flags to a degree.

This fixes two regressions: one introduced when adding %mkbuilddir that nukes your current directory with no questions asked if --build-in-place is used before it even starts, and an earlier one from commit b34333fa021c0ee7215714eeef96d1a2843ea08e that would nuke your precious in-place directory afterwards. And as a side-effect of all this, debuginfo generation also now works with --build-in-place.

Fixes: #3122
Fixes: #3042
You can view, comment on, or merge this pull request online at:

  https://github.com/rpm-software-management/rpm/pull/3124

-- Commit Summary --

  * Make --build-in-place much less of a hack and also, work

-- File Changes --

    M build/parsePrep.c (17)
    M tests/rpmbuild.at (55)
    M tools/rpmbuild.c (8)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/3124.patch
https://github.com/rpm-software-management/rpm/pull/3124.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3124
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/pull/3124 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20240523/2e5e44fb/attachment-0001.html>