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.
~link
_______________________________________________
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/golang@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
