Documentation does not mention Windows binary of Skopeo.

[tandeday]

A quick read of the documentation did not immediately reveal how I got a Windows (10 if that matters) binary of skopeo for me to use against our OpenShift cluster. I do not have Go experience so I didn't just go ahead and build it.

It would be nice if the documentation clearly stated:

• If a binary is available for download (probably isn't).
• How to create one if possible? (along with a difficulty estimage).
• If not possible within reason, then explicitly mention that.

Thanks

/Thorbjørn

[vrothberg]

Hi @m86194, thanks for opening this issue.

We don't offer binaries for any OS. Skopeo is (build) tested against Linux and Mac OS but I am not sure how far we can come on Windows. I don't have access to a Windows machine for testing.

@mtrmac @rhatdan WDYT?

[mtrmac]

We do test Windows cross-compilation of c/image, so it is probably buildable, but I wouldn’t be at all surprised if Skopeo were a pretty bad Windows citizen (WRT configuration file paths and the like), and not extremely surprised if it were broken due to different path syntax or the like (though there was at least one Windows-based user of the c/image library at one point).

make binary-local would be the default way to try to build it, adding some BUILDTAGS might be necessary.

Frankly, making Windows work, and work smoothly, and having everything well documented, would be mostly dependent on someone interested contributing that. We are definitely interested, at least enough not to sabotage that :) , but lack both access and time to do it ourselves.

Same for providing pre-built binaries; on Linux it is more or less an intentional choice not to, because a single binary is not portable to various Linuxes; on Windows it might be more practical, but again dependent on someone integrating that into the current build system.

[xphyr]

SO, it very much seems possible. I was able to build a Windows binary just this evening (completely unrelated to @m86194 request). I made a small tweak to the Makefile (created a Windows build target) and it does compile. I will test it out tomorrow at work on a Windows machine and see if its usable. If you are curious about the addition to the Makefile take a look at my fork of this project.

[tandeday]

First of all, please notice I am not requesting a windows build (which would be nice, though) but that the documentation is clearer about what can be expected from a new user coming to the project. (I need a dockerless image mirrorer) because it is slowly showing up in google searches for this kind of utility.

I fully understand that you have limited resources and this is to be considered an internal Redhat tool which just happens to be useful to others, instead of a fully funded product. I am just letting you know that people like me want to know this pretty quickly when triaging posibillities.

@xphyr this sounds very interesting. If it is usable, I'd like to have a look at it. Thanks.

[rhatdan]

Well, first of all this is not an Internal Red Hat Tool. Skopeo is a fully open source project and we welcome it running on any platform. Linux, MAC, Windows ...

If we get contributors working on the Windoews and MAC Ports that would be great. The primary developers right now are Linux users and therefore it gets the most attention.

We are working to make Podman easier to consume on Windows and MAC, so I don't see a reason why we would not want to get Skopeo easily available on those platforms as well.

[xphyr]

I was able to test the windows binary and it works for what we needed (doing remote inspection of images). From an initial look, I believe the Mac Port and Windows port would be similar in nature, leveraging the "binary-static" targets in the Makefile to eliminate anything that requires CGO or linux only features like brtfs. I will take some additional time over the next few days to try and test the other functionality of the tool on these non-linux OSes.

[rhatdan]

Great, thanks for looking into this.

[xphyr]

Over the weekend I tested the functionality of the Windows and OSX builds, using the Make file in my fork and I documented the results in the readme as well. Generally speaking, inspect, copy & delete work, as does the various storage subsystems except those specifically tied to the linux operating system (such as "ostree support"). It looks like this was known for OSX, but not for Windows.

If there is interest, I would be happy to work on a binary release process for OSX/Windows so that others could leverage this tool on alternative platforms without the need for installing Go and Make. My first thought would be to either use either:

• goreleaser as part of the Travis CI build process
• the native TravisCI release module.

Please let me know if this is something you would like to accept into the project and I will work on putting it together.

[rhatdan]

Yes, I think we are very interested in this.

[vrothberg]

Absolutely, thanks for looking into this, @xphyr !

[xphyr]

I have been able to make relatively few changes to the build process and I now have a travis build that runs against Linux, OSX and Windows and passes all tests successfully. I am now working on how to get travis to create a github "release" so that we can upload a compiled binary for windows and osx. The on-going work is in my fork if anyone is interested in seeing progress or has any feedback.

[mtrmac]

Great!

Some quick observations looking at that branch (without checking to verify that what I’m talking about is practical right now, it may just be my ignorance):

• If possible, I’d like to minimize proliferation of build targets, and rule duplication; e.g. the primary make binary-local target, when run on macOS/Windows, should automatically produce a working macOS/Windows binary, and we shouldn’t need to tell the users to run different commands on different systems. (Your work already moves in this direction, with the OS/name conditionals). cross-OS build targets may still be useful, but they are distinctly secondary to native builds, and ideally should reuse, not duplicate, the primary build rules (e.g. a binary-local-windows target could just be make binary-local OS=Windows_NT or something like that).
• We’re, by default, emphasizing the non-container builds (make binary-local); if they work, and they are the only ones used by CI, I’m not sure we even need the container ones to be added; they bring little value and are somewhat likely to be broken without anyone noticing.
• At least on Linux, the default is to use dynamic, not static, linking, unless there is a good reason (dynamic linking is preferred to allow independent updates of the called libraries, including security fixes). I’m not sure whether this applies to macOS/Windows as well (I don’t know all that much about them) – it may well not be the same – but I’d like this to be, eventually, at least explicitly discussed.

[xphyr]

Thanks @mtrmac for the feedback. I agree the multiple build targets was getting a bit much, and I really like your solution. I will look to incorporate this into the work I am doing.
I will need to look more into static vs dynamic linking on macOS/Windows. I will admit ignorance here and say that I have only ever built static binaries for these OSes. One of the things that has made building the Windows binary more challenging is the CGO requirement for gpgme in the containers/image library. I may look into this next, just to see if there is a solution to this problem as my next project to tackle ...

[xphyr]

End of the weekend update, my football team lost, but I was able to clean up the multiple build targets, and make "make" do something much more sane. I am now detecting the need for "containers_image_openpgp" dynamically, similar to the detection of OSTREE, LIBDM and BTRFS tags. This has us back to just "binary-local" and "binary-local-static" targets. I have also backed out the explicit requirement to build static and the BUILD_OS is auto-detected on start, but can be over-ridden for testing purposes.

I also had success in publishing a Windows and OSX build binary to my fork. I have done a preliminary test of the Windows binary and it works. If you check my fork under releases you will see a Windows and OSX (darwin) release file for version 0.1.40-xphyr.

I am wondering if I should tackle #580 while I am in the Makefile making changes. After reading 580, as well as the comments above about not needing containers should I attempt to strip the container build targets from the Makefile, or do we want to do that as a separate PR (if at all).

[sebastianwebber]

hello all!

do you guys still have an interest to use GoReleaser to make the releases? Can I open a PR?