I have run into a few of these getting --build-in-place to work for systemd,
let me post my workarounds here as extra information:
> the only way --build-in-place really makes sense is doing vpath builds, but
> we don't natively support that in rpm (yet)
I implicitly assume that I can set vpath_builddir which is luckily supported
everywhere via distribution macros
> %patch should be disabled with --build-in-place because it's not a pristine
> source we can return to
> source/patch meaning is questionable in the first place, because it's not
> what we build there
I added a `BuildSourcesEphemeral=` option in
[mkosi](https://github.com/systemd/mkosi) which mounts a writable overlay on
top of the build sources that is thrown away after the build. This way the spec
can patch and change all it wants without those changes persisting after the
build.
> build-in-place always requires spec to be aware of the action, should it
> instead be an option to %setup instead of cli? or maybe it should just skip
> %prep entirely, that seems more appropriate for the cause
For the systemd spec we had to add `%version_override`, `%release_override` and
`%upstream` macros. The first two allow us to build rpms that are guaranteed to
be newer than previous ones. We set the version override to the upstream
version in git and set the release override to the timestamp of the git commit
(or current unix timestamp if the tree is dirty). The upstream macro allows us
to accomodate build system changes or other customizations that are only
desired for --build-in-place upstream builds.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3131#issuecomment-2136723330
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/issues/3131/2136723...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
