Hi Link,
Hau idatzi du Link Dupont (link@sub-pop.net) erabiltzaileak (2023 eka. 29(a), og. (18:03)):
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
https://src.fedoraproject.org/rpms/golang-uber-atomic exists
- golang-github-hashicorp-multierror -
https://src.fedoraproject.org/rpms/golang-github-hashicorp-multierror exists
As well as the dependent database packages:
- golang-github-mattn-sqlite3 - https://bugzilla.redhat.com/2216821
https://src.fedoraproject.org/rpms/golang-github-mattn-sqlite3
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.
I think one approach to be able to use %go_generate_buildrequires can be to either remove dirs from database dir or either patch/sed them in %prep to use "build ignore".
Otherwise the spec seems sane, but will require some changes.
Regards, Mikel