search

gofed / go-macros

Rpm mechanics for Go packaging
4 stars 7 forks source link

In all package layout cases, the dependency chain triggered by the #27

Closed nim-nim closed 5 years ago

nim-nim commented 6 years ago

BuildRequires in %gometa must go first through go-rpm-macros that will require golist and compiler(go-compiler).

└──────────────────────────────────────┘ └───────────────────────────────────────────────────────────────────┘ What exists from a package maintenance What exists for the software installer, on the target systems and point of view. Direct 1:1 mapping is for installing the buildroot. Does not care what is the source desired to limit maintenance costs and package from which those packages were built making sure all the parts of a project are made available simultaneously during a Fedora compose


Note how the upstream project names and the spec project names actually
match, and how the important macro file names patch the name of the
package that provides them and the corresponding requires (for
go-srpm-macros and go-rpm-macros the match is not perfect, due to the
precedence in Fedora on calling this kind of packages foo-rpm-macros and
foo-srpm-macros, so that’s how humans expect those packages to be
named.)

If you prefer you can replace the go-compiler-golang and go-compiler-gcc
package names with go-compiler-golang-macros and go-compiler-gcc-macros.
A bit longer but more exact, consistent with the rest and with a link to
the src.rpm name

* Alternative more complex and expensive to maintain layout. The dependency chains at the package
level are the same.

upstream project spec/src.rpm deployment(sub-)packages

                                         ┌─╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌─╌╌╌╌╌╌╌╌╌╌╌┐

go-macros────────┬─▶go-srpm-macros──────────▶┊go-srpm-macros◀─────────────────────────────────────────┐ ┊ Actual buildroot content Version: X │ Version: X ┊ Version: X │ ┊ Dangerous files for other packages forbidden Macro files │ ┊ Architecture: noarch │ ┊ Requiring packages outside the buildroot forbidden and shell │ ┊ Files: │ ┊ Being required for version-lock is allowed wrappers │ ┊ /usr/lib/rpm/macros.d/macros.go-rpm R: go-srpm-macros = X ┊ │ └─╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌┘ │ │ └─▶go-rpm-macros─────────┬──▶go-rpm-macros───────────────────────────────────────────┼───────────┐ Version: X │ Version: X │ │ │ Architecture: noarch R: compiler(go-compiler) │ │ Files: │ │ │ /usr/bin/go-rpm-integration │ R: golist │ /usr/lib/rpm/fileattrs/go.attr │ │ │ /usr/lib/rpm/fileattrs/gobundled.attr │ │ │ /usr/lib/rpm/fileattrs/gosymlink.attr │ │ │ /usr/lib/rpm/gobundled.prov │ │ │ /usr/lib/rpm/gosymlink.deps │ │ │ /usr/lib/rpm/macros.d/macros.go-rpm │ │ │ │ │ ├──▶go-compiler-golang◀─────────────────────────────────────┤ │ │ Version: X │ │ │ Architecture: arch │ │ │ Provides: │ │ │ compiler(go-compiler) = 2 │ │ │ compiler(golang) │ │ │ Files: │ │ │ /usr/lib/rpm/macros.d/macros.go-compiler-golang │ │ │ │ │ └──▶go-compiler-gcc◀────────────────────────────────────────┘ │ Version: X │ Architecture: arch │ Provides: │ compiler(go-compiler) = 1 │ compiler(gcc-go) │ Files: │ /usr/lib/rpm/macros.d/macros.go-compiler-gcc │ │ symbols-extractor──▶go-symbols-extractor─────▶go-symbols-extractor◀───────────────────────────────────────────────┘ Version: Y Version: Y Version: Y Go code Architecture: arch Provides: golist Files: /usr/bin/golist

└──────────────────────────────────────┘ └───────────────────────────────────────────────────────────────────┘ What exists from a package maintenance What exists for the software installer, on the target systems and point of view. Direct 1:1 mapping is for installing the buildroot. Does not care what is the source desired to limit maintenance costs and package from which those packages were built making sure all the parts of a project are made available simultaneously during a Fedora compose

ingvagabund commented 6 years ago

I will not close this one cause it may proof to be practical later. Currently it is "nice to have" from my point of view. Let's do "nice to have" later once we have running and functioning base for all our blocking use cases.