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

Reply via email to