feat: add option to set %_target_os

[hicom150]

This PR adds the option to define the %_target_os that it is used in the target option of rpmbuild.

--target PLATFORM
When building the package, interpret PLATFORM as arch-vendor-os and set the macros %_target, %_target_cpu, and %_target_os accordingly.

This PR is related to webtorrent/webtorrent-desktop#1849 as the maintainer uses osx (darwin) to generate linux packages.

[fcastilloec]

I'm sorry but RPM will always override all %_target, %_target_arch, and %_target_os no matter what values we decide to put here.
If these values will be allowed to be set by the user, you could simply just use .rpmmacros to override them, or just make changes to the installer so it can accept arch: x86_64-felipe-gnu rather than two additional options.
This is all done so people don't build for a wrong architecture and OS, you can read more here https://docs.fedoraproject.org/ro/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch-rpmbuild.html

[hicom150]

Thank you @fcastilloec for your feedback! 👍

I think I've not explain myself very well 😅 My intention was to change %_target_os but throw rpmbuild --target option composing with ${this.options.arch}-${this.options.vendor}-${this.options.os} so we can create rpm package targeted to a different OS than the host OS.

This is based on the rpmbuild documentation where it says

--target PLATFORM
When building the package, interpret PLATFORM as arch-vendor-os and set the macros %_target, %_target_cpu, and %_target_os accordingly.

In my case, with this PR merged, I'm able to successfully create a linux targeted rpm from a macOS (darwin) host.

[hicom150]

Given that #176 has been already merged, do you find possible to try to push this forward? 😉

[feross]

@fcastilloec is it possible to address @hicom150's response to your feedback? ❤️

[fcastilloec]

I'll be taking another look at this PR in the next weeks. I've just been very busy.

I'm still a little hesitant into introducing this feature, I do believe that it's always better to build the package in the same machine that's intended for use. Nonetheless, I see that this is not always possible, even with so many free CI services around.

[fcastilloec]

I've made some changes. The most important ones: rebasing against our latest main branch so we can run the tests under macOS, and fixing the tests which weren't asserting anything.