Package: wnpp Severity: wishlist Owner: Reinhard Tartler <siret...@tauware.de>
* Package name : golang-github-openshift-imagebuilder Version : 1.0+git20190212.3682349-1 Upstream Author : OpenShift * URL : https://github.com/openshift/imagebuilder * License : Apache-2.0 Programming Lang: Go Description : Builds Dockerfile using the Docker client This library supports using the Dockerfile syntax to build OCI & Docker compatible images, without invoking a container build command such as buildah bud or docker build. It is intended to give clients more control over how they build container images, including: • Instead of building one layer per line, run all instructions in the same container• Set HostConfig settings like network and memory controls that are not available when running container builds• Mount external files into the build that are not persisted as part of the final image (i.e. "secrets")• If there are no RUN commands in the Dockerfile, the container is created and committed, but never started. The final image should be 99.9% compatible with regular container builds, but bugs are always possible. This is a build dependency of the buildah tool. A particular challenge with this package is that it vendors in an old version of the "docker" library. This has been reported by one of the maintainers of the buildah project as https://github.com/openshift/imagebuilder/issues/116 Upstream doesn't appear to be willing to upgrade to a new version (quote from the bug above "[...] I really don't want to [...]". Looking at how this package is using the vendored library, it seems openshift/imagebuilder is using a rather specific subset of the docker code, some of which possibly shouldn't have been exposed in the first place. Therefore, I'm inclined to follow upstream and vendor this library. My question here is what is the best way of implementing this. I could update the Files-Excluded field in debian/copyright to exclude all entries but openshift/imagebuilder, and use mk-origtargz to strip the tarball. That would, however, lead to a *very* elaborate Files-Excluded field. I wonder whether it wouldn't be actually be more appropriate to create a tarbal with the vendored library and ship it in the debian/ subdirectory. Has anyone else encountered this issue and/or could point to other packages solving the same or a similar issue? Cheers, -rt
