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
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!
Quite large. That's part of what prompted my approach. And each of these backends has its own potential pile of additional dependencies.
GOPATH=/home/link/go GO111MODULE=off golist --imported --package-path github.com/golang-migrate/migrate cloud.google.com/go/spanner cloud.google.com/go/spanner/admin/database/apiv1 cloud.google.com/go/spanner/admin/database/apiv1/databasepb cloud.google.com/go/spanner/spansql cloud.google.com/go/storage github.com/Azure/go-autorest/autorest/adal github.com/aws/aws-sdk-go/aws github.com/aws/aws-sdk-go/aws/session github.com/aws/aws-sdk-go/service/s3 github.com/aws/aws-sdk-go/service/s3/s3iface github.com/cenkalti/backoff/v4 github.com/cockroachdb/cockroach-go/v2/crdb github.com/dhui/dktest github.com/docker/docker/api/types github.com/docker/docker/api/types/container github.com/docker/docker/api/types/network github.com/docker/docker/client github.com/go-sql-driver/mysql github.com/gocql/gocql github.com/golang-migrate/migrate/v4 github.com/golang-migrate/migrate/v4/database github.com/golang-migrate/migrate/v4/database/multistmt github.com/golang-migrate/migrate/v4/database/stub github.com/golang-migrate/migrate/v4/internal/cli github.com/golang-migrate/migrate/v4/internal/url github.com/golang-migrate/migrate/v4/source github.com/golang-migrate/migrate/v4/source/file github.com/golang-migrate/migrate/v4/source/github github.com/golang-migrate/migrate/v4/source/httpfs github.com/golang-migrate/migrate/v4/source/iofs github.com/google/go-github/v39/github github.com/hashicorp/go-multierror github.com/jackc/pgconn github.com/jackc/pgerrcode github.com/jackc/pgx/v4/stdlib github.com/jackc/pgx/v5/pgconn github.com/jackc/pgx/v5/stdlib github.com/ktrysmt/go-bitbucket github.com/lib/pq github.com/markbates/pkger github.com/markbates/pkger/pkging github.com/mattn/go-sqlite3 github.com/microsoft/go-mssqldb github.com/mutecomm/go-sqlcipher/v4 github.com/nakagami/firebirdsql github.com/neo4j/neo4j-go-driver/neo4j github.com/snowflakedb/gosnowflake github.com/xanzy/go-gitlab go.mongodb.org/mongo-driver/bson go.mongodb.org/mongo-driver/mongo go.mongodb.org/mongo-driver/mongo/options go.mongodb.org/mongo-driver/x/mongo/driver/connstring go.uber.org/atomic golang.org/x/oauth2 golang.org/x/tools/godoc/vfs golang.org/x/tools/godoc/vfs/httpfs google.golang.org/api/iterator modernc.org/ql/driver modernc.org/sqlite
On Mon, Jul 17 2023 at 10:12:51 AM -04:00:00, Neal Gompa ngompa13@gmail.com wrote:
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! _______________________________________________ golang mailing list -- golang@lists.fedoraproject.org To unsubscribe send an email to golang-leave@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
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
Wow. I don't know how I missed those existing packages. I think perhaps after I stopped using %go_generate_buildrequires, I assumed those packages didn't exist.
I'd think I'd rather take an additive approach to the optional backends and sources. It feels more intuitive to add support for a backend by adding the tag name to the macro and adding the dependent package requirements than by deleting the patches that omit the backend. (I even had trouble figuring out how to write all the double-negatives in that sentence!)
On Mon, Jul 17 2023 at 04:32:18 PM +02:00:00, Mikel Olasagasti mikel@olasagasti.info wrote:
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 _______________________________________________ golang mailing list -- golang@lists.fedoraproject.org To unsubscribe send an email to golang-leave@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
golang@lists.fedoraproject.org
-
Link Dupont -
Mikel Olasagasti -
Neal Gompa