upload/koji: use the new API of kolo/xmlrpc by default
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.
This commit is contained in:
parent
d32345104c
commit
a67baf5a4d
15 changed files with 190 additions and 108 deletions
5
vendor/github.com/kolo/xmlrpc/decoder.go
generated
vendored
5
vendor/github.com/kolo/xmlrpc/decoder.go
generated
vendored
|
|
@ -130,8 +130,9 @@ func (dec *decoder) decodeValue(val reflect.Value) error {
|
|||
ismap = true
|
||||
} else if checkType(val, reflect.Interface) == nil && val.IsNil() {
|
||||
var dummy map[string]interface{}
|
||||
pmap = reflect.New(reflect.TypeOf(dummy)).Elem()
|
||||
valType = pmap.Type()
|
||||
valType = reflect.TypeOf(dummy)
|
||||
pmap = reflect.New(valType).Elem()
|
||||
val.Set(pmap)
|
||||
ismap = true
|
||||
} else {
|
||||
return err
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue