@pmatilai converted this issue into discussion #2654.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2590#event-10342508518
You are receiving this because you are subscribed to this thread.
Message ID:
To your comment:
> in some workflows people receive an srpm from somewhere and build that.
my answer is precisely that. **When I try to rebuild the single package the
process fails at the end of a 3-hour build run with an extremely obscure error
message.** Yet somehow it seems to work with
ok, so it depends on your point of view, that's clear. For downstream
"repackagers" there's clearly internal macro "mangling" and perhaps build
environment differences specifically due to that, and while that's clearly a
very important use case it's not the same as mine. It may be that some
> I'm also aware that if you run `rpmbuild -bs .spec` there's no binary
> build process going on so I'd guess it's quite possible that macro
> definitions and installed package lists may not actually be useful. However,
> if you build source and binary packages together, which I'd assume is
Also related to your comments about how rpm works with dependencies:
I'm aware of rpm dependencies. I've been building rpm packages since RedHat
3.0.3 (that's in 1996). Also I'm not the owner of the rpms I want to rebuild
so it's not a matter of me rebuilding my rpms it's also a matter of me
In the end **as a first step** I'd like to be able to reproduce the builds as
close to what the original builder did. So I'd like that build to be
reproducible in the way referenced in the URL.
- One thing is to record the rpm macro values used during the build process.
- another simple thing
