nim reported a new issue against the project: `go-rpm-macros` that you are following:
`%goprep` should apply patches automatically, so there is no convenience gap with `%autosetup`.
This is generic work that should be done *redhat-rpm-config* side in forge macros and then reused in`%goprep`. Basically:
1. define a `patch_flags<suffix>` rpm variable holding the parameters that should be passed to `%patch<suffix>`
2. define a `default_flags<suffix>` fallback
3. define a `source_patches<suffix>` holding an ordered space separated list of patch suffixes associated with a particular forge/go source.
And then write the usual lua loops to apply it all at the right moment in the spec.
To reply, visit the link below or just reply to this email
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
* 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
* golang-uber-atomic - https://bugzilla.redhat.com/2216829
* golang-github-hashicorp-multierror -
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.
Someone just orphaned the golang-cloud-google package package. I am
interested in this package because it appears to be an indirect
dependency for Hugo. The note at
"Orphaned for: Other -- Updates to this package have a cascading list
of requirements from arrow (> 40 packages last count)"
Can anyone elaborate on this? What does "requirements from arrow" mean?
I would be willing to take ownership of golang-cloud-google, but the
message above gives me pause.
Was there an alternative plan to make adjustments to the package that
depends on golang-cloud-google so that golang-cloud-google is no longer