This commit makes it possible to *not* to use `rpm-ostree` even on
systems where it is detected.
This commit is fully backwards compatible with previous releases, and
without changing the config file all previous behaviors are the exact
same.
This commit adds the `rpm_ostree` field in the `[linux]` table of the
configuration, and defaults to `true`. This means Topgrade will first
check if `/usr/bin/rpm-ostree` exists, and only if so then check if the
user does not want to use `rpm-ostree` via the configuration. If the
user *does not* want to use `rpm-ostree`, then normal operation
continues checking for DNF or YUM.
This makes it possible for people where `rpm-ostree` is installed, but
where the system is not an `ostree` based distribtuion. This happens
when people are using things like `osbuild-composer` to build images,
or Cockpit with the Compose feature enabled (which uses
`osbuild-composer` internally).
An alternative to this commit would be to make the config field a
negative such as `no_rpm_ostree`, however that goes against the norm in
other fields.
Closes#710
Despite the fact that Topgrade explicitly tries to run the Windows Powershell, gsudo has an odd behaviour which causes it to detect whether it's being run from Powershell for Cmd.
If run from Powershell, It will launch the current powershell with the given command. If the current shell is Powershell, it will try to run the command with it.
However, Get-WmiObject doesn't exist on Powershell core.
* Drop the Go step
With the release of Go 1.16 the behavior of `go get` has been changed.
In previous Go versions `go get` was used not only to add module
dependencies but also to install Go tools.
As of Go 1.16 `go get` can only add and upgrade module dependencies.
To install Go tools now the `go install` command has to be used.
Further on Go 1.16 enabled the GOMODULE mode by default and will drop
the GOPATH mode completly in Go 1.17.
So the package definition `all` like in `go get -u all` does not work
anymore if the PWD is outside of a Go module project.
Because of this `go list all` also does not work for the same reason.
That being said it seems that currently there is no way to get a list of
all installed Go tools or packages at the GOPATH level.
So the only possible solution to determine the installed Go tools and
also to update them would be by inspecting the `go env GOBIN` directory
as well as the `go env GOMODCACHE` sub-directories and to filter the
results according to their possible name-to-package boundaries.
As this approach seems to be very ugly and also not to be very safe or
stable and Go currently does not support any kind of automated upgrades
of installed Go tools it is best to drop the Go step for now until Go
implements some kind of Go tool upgrade feature.
Fixes#659
* Remove Go from Step enum
The GOPATH env variable usually is not set on any system because Go
uses its own env management via `go env` command.
Also `go env GOPATH` is not on all systems the same as `$HOME/go`.
On such systems topgrade would use the wrong GOPATH.
If the `go` command is installed then `go env GOPATH` will always print
something.
If GOPATH is set then `go env GOPATH` will print the value of GOPATH,
otherwise `go env GOPATH` will print the GOPATH value of the Go env
config.
