`defaultHelperBinariesDir` doesn't play well with new Podman installer on Windows

[arixmkii]

Issue Description

It has been hardcoded in the past, but since the install directory was moved into user specific location this default is not relevant anymore. It probably should have no default + override set by the installer itself.

It might have already workarounds present for WSL and Hyper-V, so, the issue would not manifest, but it still could manifest in the future.

For my scenario it manifested in QEMU code, which uses shared common lookup on all platforms (no platform specifics in this code path)

The code in question is located at https://github.com/containers/common/blob/a5ccdae846b629b5ceaefa6ffd5c6511409c3487/pkg/config/config_windows.go#L34

Steps to reproduce the issue

Steps to reproduce the issue

1. Compile Podman with QEMU support on windows and build modern installer
2. Install Podman, setting default machine provider to QEMU
3. Create and start Podman machine

Describe the results you received

Error starting machine, because gvproxy could not be found.

Describe the results you expected

Machine started. This would probably still be the case with legacy installer.

podman info output

Don't have this output, but it was a build with patches applied on top of v5.7.0 tag.

Podman in a container

No

Privileged Or Rootless

None

Upstream Latest Release

Yes

Additional environment details

Windows machine with QEMU installed.

Additional information

QEMU is not officially supported, but this default still doesn't make sense and could manifest later if code from common is reused for some feature.

Also, one of the goals of the new installer was to move away from vendor specific location, because of the project aiming for more vendor neutrality migrating to CNCF.

[Luap99]

@l0rd PTAL

The hard coded path should be removed. I don't think qemu would matter even, does it? The gvproxy binary is looked up using FindHelperBinary() so the installer would need to put it in the right places.

Given we can only compile hard coded paths I guess the only logical solution would be for the machine installer to create the containers.conf file with helper_binaries_dir set to the right install location?

[arixmkii]

I don't think qemu would matter even, does it?

Yes, it doesn't matter (I just needed to highlight that this was not tested with the official build, but rather a modified, but I provided link to the code, which looks incorrect). It is just the version I had time to test.

Given we can only compile hard coded paths I guess the only logical solution would be for the machine installer to create the containers.conf file with helper_binaries_dir set to the right install location?

Yes, I think setting this to empty list on Windows and handling the config in the installer is the right approach.

[l0rd]

The hard-coded path should be removed. It's a leftover.

Instead of delegating the config to the installer, we can use FindHelperBinary that can look in the podman.exe folder if we specify $BINDIR:

var defaultHelperBinariesDir = []string{
	// Relative to the binary directory
	"$BINDIR",
} 

We should also use this opportunity to fix a WSL inconsistency. The WSL code doesn't call FindHelperBinary (note how StartNetworking is called before FindHelperBinary and the gvproxy.GvproxyCommand parameter is null). The gvproxy/winssh-proxy path is retrieved using FindExecutablePeer (that looks in podman.exe folder).

[Luap99]

Using BINDIR SGTM

[l0rd]

I confirm that the issue exists with Hyper-V. I am testing the fix using $BINDIR as default on Windows. And using FindHelperBinary for WSL too.