a67baf5a4d
Fedora 33 ships the new API so let's do the switch now. But... this would break older Fedoras because they only have the old API, right? We have the following options: 1) Ship xmlrpc compat package to Fedora 33+. This would mean that we delay the API switch till F32 EOL. This would be the most elegant solution, yet it has two issues: a) We will surely not be able to deliver the compat package before F33 Final Freeze. b) It's an extra and annoying work. 2) Downstream patch. No. 3) Use build constraints and have two versions of our code for both different API. I chose solution #3. It has an issue though: %gobuild macro already passes -tags argument to go build. Therefore the following line fails because it's not possible to use -tags more than once: %gobuild -tags kolo_xmlrpc_oldapi ... Therefore I had to come up with manual tinkering with the build constraints in the spec file. This is pretty ugly but I like that: 1) Go code is actually clean, no weird magic is happening there. 2) We can still ship our software to Fedora/RHEL as we used to (no downstream patches) 3) All downstreams can use the upstream spec file directly. Note that this doesn't affect RHEL in any way as it uses vendored libraries. |
||
|---|---|---|
| .. | ||
| xmlrpc | ||