Not having golang.org/x/crypto/ssh/terminal explicitly listed as a
BuildRequires isn't breaking the build at the moment. However, since
it's a direct dependency, and Toolbx is written in Go, it's good to
explicitly list it due to the statically linked nature of Go binaries.
It will make it easier to gauge the fallout from a security bug.
There's no need to do a build just for this.
Earlier Viper was being pulled in by Cobra, and hence wasn't explicitly
listed as a BuildRequires. However, Cobra 1.4.0 removed the Viper
dependency [1], so it needs to be explicitly listed.
There's no need to do a build just for this.
[1] Cobra commit 5b2b9e9f61d36ccb
https://github.com/spf13/cobra/issues/1597
The 'go-md2man' virtual Provides was briefly lost after the
golang-github-cpuguy83-go-md2man package was renamed to
golang-github-cpuguy83-md2man. The virtual Provides has since been
restored [1], and go-md2man is being used as a standalone binary tool,
not as a Go package that's imported into Toolbx's source code. Hence,
it makes sense to refer to the tool as go-md2man, and not by it's
import path.
This reverts commit 701836afca.
There's no need to do a build just for this.
[1] golang-github-cpuguy83-md2man commit c085b15e5acd8d07
https://src.fedoraproject.org/rpms/golang-github-cpuguy83-md2man/c/c085b15e5acd8d07
The krb5-libs package is necessary to ensure the presence of the
/etc/krb5.conf.d directory with the correct permissions. However, it's
not strictly necessary and toolbox(1) can work without it.
https://src.fedoraproject.org/rpms/toolbox/pull-request/4
The test suite has been temporarily disabled because ShellCheck 0.7.1
triggers SC2086 for some unquoted variables. It should be re-enabled as
soon as it's fixed upstream.
Toolbox is now written in Go, so this is no longer a noarch package.
Unlike idiomatic Go code-bases, Toolbox uses the Meson build system to
check for additional non-Go dependencies and install various auxilliary
files. This leads to some interesting problems.
The Go toolchain doesn't play well with passing compiler and linker
flags via environment variables. The linker flags require a second
level of quoting, which leaves the build system without a quote level
to assign the flags to an environment variable like GOFLAGS.
This is one reason why Fedora doesn't have a RPM macro with only the
flags. The %{gobuild} RPM macro includes the entire 'go build ...'
invocation.
Therefore, the entire 'go build ...' invocation is swapped out using a
set of downstream patches (one for PPC64 because it doesn't use
'-buildmode pie', and another for other CPU architectures) to match
the %{gobuild} RPM macro.
The Go toolchain also doesn't like the LDFLAGS environment variable as
exported by Fedora's %{meson} RPM macro.
For some reason, when built on Koji, the final binary gets created as
../src/src instead of ../src/toolbox, but it doesn't happen when
building locally with 'rpmbuild -ba ...'. Hence it's necessary to
explicitly specify the name of the output binary.
Finally, Fedora doesn't support Go modules when building Go programs.
This means that Go's semantic import versioning can't be used.
A conscious effort was made to minimize the use of exotic Go-specific
RPM macros to retain the legibility of the spec file. A proliferation
of such RPM macros is a hindrance for those who are not experts in the
ins and outs of packaging Go code in Fedora.
Some changes by Debarshi Ray.
https://src.fedoraproject.org/rpms/toolbox/pull-request/2
These are intended to be installed into the image if the image doesn't
use the fedora-toolbox container as the base image - all the packages
are already preinstalled there.
The support subpackage should be installed to images that intent to
work flawlessly with toolbox.
The experience subpackage should be installed as well, to provide the
same experience while working in the container as one would get on the
host.
https://src.fedoraproject.org/rpms/toolbox/pull-request/1
