Makefile: rename build artifact for windows and darwin

[vrothberg]

Rename podman-remote to podman.exe on Windows and to podman on Mac
OS. The -remote suffix isn't needed since Podman does not run
natively on these systems.

Signed-off-by: Valentin Rothberg [email protected]

[baude]

lgtm

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vrothberg

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [vrothberg]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[vrothberg]

Requested in crc-org/crc#2171.

[vrothberg]

Needs some more massaging

[mheon]

@cevich PTAL - will this break the Cirrus jobs that build binary artifacts?

[cevich]

I don't think so, but thanks for checking. The problem I intended to fix in #9381 is more related to the order of targets. Though @vrothberg be warned...this area of the Makefile is very delicate 😕 My plan is to get back onto that PR, after my get_ci_vm wounds scab over 😁

[TomSweeneyRedHat]

@vrothberg unhappy red tests

[vrothberg]

@rhatdan @gbraad WDYT?

[gbraad]

We will deliver integration of Podman with CRC, but the current binary names aren't consistent:

For example, the V2.2.1 releases are:

• macOS: podman-remote-release-darwin.zip
  • podman
• Windows: podman-remote-release-windows.zip
  • podman.exe
• Linux: podman-remote-static.tar.gz
  • podman-remote-static

This would mean that the binary on Windows is named podman. This would indicate the binary does more than just being a remote client. While for use on Linux that would make sense. I understand it is not an aesthetically pleasing solution, as we want to increase the notion of podman... but in short, we will also be lying to the user. On Linux this would make sense, as we want ot prevent a clash with a possible installed version of the actual podman command.

I would also like to see consistent naming in the release artifacts, as the current artifacts include -release for Windows and macOS

[vrothberg]

Thanks, @gbraad!

I'll wait a bit for consensus until pushing the PR forward.

[rhatdan]

Podman-remote on a MAC should be called podman.
Podm,remote.exe on a Windows box should be called podman.exe

Users think in terms of Podman, they don't really care if it works locally or remote. Only on linux should we call podman-remote podman-remote, since native podman is there and almost no-one will ever use podman-remote on a linux box, unless you want a smaller binary and only want to use remote connections.

I think we should just make make create bin/windows/podman.exe and bin/darwin/podman.

[cevich]

bin/windows/podman.exe and bin/darwin/podman.

I like that idea, it might allow simplifying the Makefile (which I plan to work on soon-ish in #9381). i.e. We already have targets for bin/podman and bin/podman-remote. Speaking of which, should we also do: bin/linux/podman and bin/linux/podman-remote for consistency sake?

[rhatdan]

Sure, although it would drive me crazy, since I am used to typing ./bin/podman

[vrothberg]

Sure, although it would drive me crazy, since I am used to typing ./bin/podman

I think that make podman{-remote} should continue placing the artifacts as before. Otherwise, we'd likely break the builds of most (all?) distros.

[cevich]

we'd likely break the builds of most (all?) distros

It's easy enough to modify the CI scripts and tests, but you do raise a good point. There may be third-party automation (like rpm or deb builds) that would need to be modified. So yeah, with that in mind, we probably should leave it as-is w/ everything under bin.

Alternate idea for Mac (maybe Windows?): Call the binary podman-remote, but make a symlink to it called podman. That could allow for some clarity of function/purpose while still permitting a reduction in typing 😁

[vrothberg]

I am less worried about Windows and Mac builds, since we provide these upstream. But the Linux binaries have many downstream users.

[mheon]

I’d be OK with placing non-Linux binaries in subdirectories at build time (will make things much simpler IMO). What we should do at install time on OS X and Windows is less clear, but providing both Podman and podman-remote makes sense to me.

…

On Fri, Apr 2, 2021 at 08:35 Valentin Rothberg ***@***.***> wrote: I am less worried about Windows and Mac builds, since we provide these upstream. But the Linux binaries have many downstream users. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9918 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3AOCBUKGISUABH23RED6TTGW2ZDANCNFSM42HIPPJA> .

[cevich]

I’d be OK with placing non-Linux binaries in subdirectories at build time
(will make things much simpler IMO).

I've now done this in #9381 and got it working. It turned out to not be so simple, but it does prevent any mixups of the binaries from one GOOS accidentally being run on another. Anyway, I think it's okay to close this PR and I'll work on incorporating it into mine.

[vrothberg]

Thank you, @cevich !