Publish binary releases to GitHub #1478
Comments
|
Thanks for your report. Historically we’ve resisted that, because various Linux distributions are not actually binary compatible enough to make a single binary that runs everywhere and integrates correctly, compare e.g. #1336 . Instead, we provide container images, see https://github.com/containers/skopeo/tree/main/contrib/skopeoimage — that seems to be missing in the installation instructions; Podman / Buildah might have more experience in this area; AFAICS they don’t currently publish stand-alone binaries either (apart from Podman-remote). @lsm5 do you know if there is anything Skopeo can/should reuse? |
|
Would compiling with the Go compiler instead of cgo help? (as @davidhay1969 mentions in that issue - what a wonderful coincidence to see a familiar name from my IBM life!) Of course, I'm not sure what those libraries are needed for with skopeo, so don't know if compiling with the Go compiler breaks some key functionality. It also seems that binary builds that work on most recent platforms would still be useful, even if they don't work correctly on an old version of Fedora or similar. Also, is it possible to statically link the dependencies like devmapper, or is that a very bad idea? |
|
I think we go through this statically linking idea every year or two. Just 10 days ago we closed. Please read these issues, before asking any questions. We prefer distro based versions of the skopeo or to run a containerized version of skopeo from your favorite distro. podman run quay.io/skopeo/stable:latest ... We had a nix version which was eventually removed. |
|
@mtrmac podman only releases the linux remote client as a static binary, https://github.com/containers/podman/releases/tag/v3.4.0 . Buildah doesn't publish any static assets https://github.com/containers/podman/releases/tag/v3.4.0 . I see a comment in podman's Makefile saying podman doesn't work well w/o CGO_ENABLED, so that's why only the @jawnsy If you're signing up to maintain the binary release part going forward and have reasonable certainty of goreleaser not breaking/blocking release, I'm cool with it. The skopeo Makefile does use a |
|
In general I think everyone can use either containers, or distribution packages that can be installed using distribution tools instead of downloading random binaries from the web, almost all of the time. The one somewhat frequent exception is a recent contributor of, or benefactor from, a specific new Skopeo feature who wants that feature to be available faster than a distribution packages a release — it does happen at least once every year, but it’s also, for most users who want that one new feature, a one-time occurrence. |
#1481 . |
|
Thanks all for the links and references! I appreciate the context and I understand better the complexity of binary builds given the need to link against various C libraries. Sorry about not searching the issue history first. Distro packages and building from source seems like a reasonable approach to me, and I understand the extra maintenance associated with maintaining this stuff. One thing to note is that Skopeo is not currently available as a distro package on Ubuntu 20.04 (LTS), though an alternative is to pin the new version instead. Would you consider a doc PR explaining how to add that pin? I'd be happy to open one. Thanks for the awesome libraries and tool! |
would this help: https://build.opensuse.org/package/show/devel:kubic:libcontainers:stable/skopeo ? |
|
I would also appreciate a lot to have static binaries (or pseudo-static binaries that only depend on the glibc[1]), for the following use-cases:
But I also understand the associated technical difficulties; when building the Docker Engine as a static binary, devmapper was a regular pain point, indeed. Rather than completely dropping static binary support, would you be OK with having e.g. instructions (perhaps even a Dockerfile or similar) to build a static binary, coming with a big warning informing of the potential issues? [1] Most of the "cloud native tools" that I use daily, or in CI/CD pipelines, are dynamic Go programs that only depend on the glibc and a reasonably recent linker. They won't work on Alpine, but they typically work on any recent glibc-based system (including some Ubuntu 18.04, and sometimes 16.04, environments). They're not truly static, but they "just work" on the vast majority of systems out there. |
I think that is a nice compromise, @jpetazzo. |
Don’t the containers serve that purpose, especially in a container-focused course?
(FWIW with Windows-native, the binary compatibility is probably not an issue, but to my knowledge no-one has worked on making Skopeo a good Windows citizen, e.g. looking for configuration files in the right places.)
Presumably the CI/CD system is not a personal Linux-from-scratch, so can it use a distribution package?
We’ve had that, using various approaches, in the So I think we’re open to a contributor maintaining such build rules, but it’s also, based on how rarely they have been used in the past, not something that warrants us investing extra maintenance effort. |
|
@vrothberg: Thanks a lot for the feedback! @mtrmac: I'll give you a couple of real-life examples. Recently, during a Kubernetes training, we hit the Docker Hub rate limits; so I showed the students how to set up and use registry mirrors. We copied some images around using Now, for CI/CD tools, it's pretty common to use someone's image and add the tool(s) that you need on top of that. If the extra tools are all static binaries, it works without any particular work. Otherwise, I have to think about "which packaging system is used here?" and that adds dependency and coupling. Furthermore, if I try to produce smaller images, a tool that carries dynamic libraries is harder to deal with. Please don't get me wrong; I'm not saying "HEY YOU SHOULD SUPPORT THIS RIGHT NOW!!!" 😃 I'm just giving you the "user stories" behind that particular need. (We had very similar conversations with the Docker core team in 2013 when figuring out how to distribute the first builds of Docker, btw!) That being said, I played a bit with the build chain tonight, and it looks like I can produce an "almost static" binary by running this from a checkout of the repo: docker run -ti -v $PWD:/src -w /src -e CGO_ENABLED=0 golang make BUILDTAGS=containers_image_openpgpInterestingly, [jp@большой (⎈ |minikube:default) skopeo]
$ ldd bin/skopeo
statically linked
[jp@большой (⎈ |minikube:default) skopeo]
$ file bin/skopeo
bin/skopeo: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=PgEimZlTOq_9gJTZ4Fku/8KQ23f8e-kzXL0H0aDSf/tmJ8847pUBISy1LyL87L/i23eSdwlzqvX3MQpbHfE, not strippedBut it runs in a bare Ubuntu container: [jp@большой (⎈ |minikube:default) skopeo]
$ docker run -v $PWD/bin:/usr/local/bin ubuntu skopeo --version
skopeo version 1.5.1-dev commit: 9c9a9f3a1f6f61e4ab2f20370d80db05b96fcdccI'm going to do some additional testing to check that it works for me; then I'll document that somewhere (with appropriate warnings of course). I'm not very happy about the whole " |
|
FWIW compare 0f458ee , which points at the last two versions of that implementation. I haven’t now tested which of the two, if any, currently works as expected. |
Following the discussion in containers#1478, we don't want to provide (and maintain) static binaries, but giving instructions to produce such builds (with appropriate warnings around these instructions) was considered acceptable, so - here we go!
Following the discussion in containers#1478, we don't want to provide (and maintain) static binaries, but giving instructions to produce such builds (with appropriate warnings around these instructions) was considered acceptable, so - here we go!
Following the discussion in containers#1478, we don't want to provide (and maintain) static binaries, but giving instructions to produce such builds (with appropriate warnings around these instructions) was considered acceptable, so - here we go!
|
I gave this another try, and after removing the |
Following the discussion in containers#1478, we don't want to provide (and maintain) static binaries, but giving instructions to produce such builds (with appropriate warnings around these instructions) was considered acceptable, so - here we go!
Following the discussion in containers#1478, we don't want to provide (and maintain) static binaries, but giving instructions to produce such builds (with appropriate warnings around these instructions) was considered acceptable, so - here we go!
Static binaries have well documented limitations and implications, nevertheless they have been enabling a wider adoption of many open source projects in a "distroless" fashion. I do not fully understand the technical motivation for this preference, can you please elaborate ? Having in consideration that static binary use cases have been presented, and interested people can contribute to the maintenance of this option, can you elaborate on the actual negative impacts for the Skopeo project of providing static binaries ? Thanks |
Following the discussion in containers#1478, we don't want to provide (and maintain) static binaries, but giving instructions to produce such builds (with appropriate warnings around these instructions) was considered acceptable, so - here we go!
Following the discussion in containers#1478, we don't want to provide (and maintain) static binaries, but giving instructions to produce such builds (with appropriate warnings around these instructions) was considered acceptable, so - here we go!
|
@joaompinto install.md mentions a list of issues and previous discussions with static binaries. |
|
@vrothberg thanks for the info. However I could not find answers to the specific questions I presented in this open issue, can you please elaborate ? Thanks |
|
Hi @joaompinto! I was hoping that the explanations that I added at the end of the install.md file would help; but perhaps they're not detailed enough. If I understand correctly, your two questions are:
The technical motivation for not having static builds is that they would lack some features, like “ .local or LDAP-based name resolution” or support for some storage backends like device mapper. I'm going to give you a loose comparison: it would be like shipping a web browser without HTTPS. Sure, it might still be useful to lots of people; but it might also be very surprising to lots of other people to realize that the browser doesn't have HTTPS. So instead, the choice was to not provide static builds, but still provide instructions for folks who really need that.
If I understand correctly, in the past, multiple people have contributed static builds (as illustrated by the GH issues referenced at the end of install.md) but each time, these build methods ended up failing, and the people who contributed them weren't around to fix them anymore, or couldn't fix them. So it ends up bringing additional burden on the maintainers. This is a frequent problem in open source projects: someone wants a feature, contributes it, but doesn't maintain it; so when the feature breaks, it's extra work for the maintainers. This is something that should be avoided. That being said, perhaps if someone wants to commit to maintaining static builds, the Skopeo maintainers would be open to merge that for good. Or, just an idea: perhaps someone (you?) could create and maintain static builds "on the side". These builds could be linked in the install.md document along the instructions we have today. If these builds remain stable and usable for long enough, that would demonstrate that the maintainers of these builds are committed to them, and then the Skopeo maintainers may decide to make them part of the official builds. I hope that makes sense! |
Yes, even without the “commit to” part:
|
|
… oh, I’m sorry, I have confused “maintaining builds” and “maintaining build rules”. We are absolutely fine with including contributed Makefile rules and the like (which is what we had in the past). I’m reluctant to officially publish static builds (and we never did publish them), because I personally believe most users should not use them, even if they happen to be the easiest option at a first glance; so, not publishing the binaries is a way to nudge users towards a second glance. (For another reason, consider that distribution packages are usually digitally signed using long-term keys that the system already trusts, in a way binaries distributed over GitHub or whatever are not; we could have our own keys, and the consumers of the static binaries could, in principle, verify signatures, but frankly most aren’t going to do that, and it’s an extra hassle for everyone.) |
|
I think you are being overzealous in this policy, and again debating as a general principle about the risk of distributing static binaries. But well, it's the freedom of Free software. I will try to publish/maintain the binaries own my own repo. Thanks for the feedback. |
|
Thanks everyone for the conversation. I think we can close the issue. |
|
I use github action ci to generate binary files. |
in ubuntu 22.04 is work! |
Thank you so much for your work, you saved my problem with source build error on Centos7 with yum install only getting old version. |
|
gorelaser may be help. |
This is an issue to discuss adding binaries to GitHub releases for skopeo. I've had good experience with using goreleaser for this, and since skopeo builds with the regular Go toolchain (e.g.
go install github.com/containers/skopeo/cmd/skopeo@latestworks great), it should be relatively straightforward to add these builds.Would you accept a pull request to add release builds?
The text was updated successfully, but these errors were encountered: