On Thu, Jun 29, 2023 at 12:03 PM Link Dupont link@sub-pop.net wrote:
Hi go-sig,
I have packaged up github.com/golang-migrate/migrate for Fedora. This project makes extensive use of build tags to include or exclude various databases and migration sources. Because of these build tags, I did not use the %go_generate_buildrequires macro. For my initial packaging of the project, I opted for a very minimal set of enabled databases and sources.
- file (stdlib)
- io/fs (stdlib)
- sqlite3 (github.com/mattn/go-sqlite3)
- postgres (github.com/lib/pq)
The package review tree involves a couple of general package requirements:
- golang-uber-atomic - https://bugzilla.redhat.com/2216829
- golang-github-hashicorp-multierror -
https://bugzilla.redhat.com/2216817
As well as the dependent database packages:
- golang-github-mattn-sqlite3 - https://bugzilla.redhat.com/2216821
Finally, the migrate package itself:
- golang-github-migrate - https://bugzilla.redhat.com/2218606
I'd like interested members of the go-sig to take a look at the spec for migrate itself to see if the approach I took in organizing the dependencies is acceptable. Because this RPM might grow in complexity as new databases get packaged and added, I would like to get the SIG's opinions on this approach.
Sorry for not seeing this sooner. The approach seems pretty reasonable to me.
Out of curiosity, how much bigger does it get if you build all the backends?
-- 真実はいつも一つ！/ Always, there's only one truth!