[Rpm-maint] [rpm-software-management/rpm] Fix header source/patch names disagreeing with src.rpm contents (PR #3067)

[Panu Matilainen]

If sources or patches in the spec are defined via a macro that does not yet exist, it'll still work for building if the macro has been defined by that time as there's another round of expansion there. But this can leave the source/patch names inserted to the header disagreeing with what actually ended up in the source package, eg in the testcase you'd previously get '%{somemacro}-2.0.tar.gz' in the header whereas the src.rpm had the right contents.

While defining sources this way seems mad and brittle, it does actually work for building rpms and there's a whole ecosystem of packages relying on it in Fedora. So lets at least be consistent about it, and re-expand the source paths once more before inserting in the header, because that's what happens for them in the actual build as well.

Originally reported at https://bugzilla.redhat.com/show_bug.cgi?id=2233878
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Fix header source/patch names disagreeing with src.rpm contents

-- File Changes --

    M build/parseSpec.c (6)
    A tests/data/SPECS/macrosource.spec (15)
    M tests/rpmbuild.at (31)

-- Patch Links --

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

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

Message ID: <rpm-software-management/rpm/pull/3067 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20240429/b54cdb77/attachment.html>