Re: Bug#923300: ITP: golang-github-openshift-imagebuilder -- Builds Dockerfile using the Docker client
On Fri, Mar 1, 2019 at 9:26 AM Reinhard Tartler wrote: > That sounds really promising. I wonder how to implement it for this > package. > > The yquake2 package uses gbp-buildpackage, pristine-tar and mk-origtargz, > which I would love to continue using. Unlike yquake2, this package doesn't > combine two seperate git repositories, but both sources come from the same > upstream repository. Also, I would like the component to be placed in the > subdirectory vendor/github.com/docker/docker, but to it seems to me that > "components" may not include the "/" (or I missed how the "/" gets > mangled). > In conclusion, this means that "components" may only be placed at the > top-level source directory. > > I guess what I can (should?) do is adjust the debian/copyright > Files-Excluded field > to exclude all entries but vendor/github.com/docker/docker, and use > declare > a 'vendor' component. Then I probably can use mk-origtargz to > create both the "orig.tar.gz" as well as the "orig-vendor.tar.gz". > > That would, however, lead to a *very* elaborate Files-Excluded field. > > I actually went ahead and implement this solution. The result can be seen at https://salsa.debian.org/go-team/packages/golang-github-openshift-imagebuilder comments / opinions welcome. I'll try using this package to build buildah locally before uploading to unstable. best, -rt -- regards, Reinhard
Re: Bug#923300: ITP: golang-github-openshift-imagebuilder -- Builds Dockerfile using the Docker client
That sounds really promising. I wonder how to implement it for this package. The yquake2 package uses gbp-buildpackage, pristine-tar and mk-origtargz, which I would love to continue using. Unlike yquake2, this package doesn't combine two seperate git repositories, but both sources come from the same upstream repository. Also, I would like the component to be placed in the subdirectory vendor/github.com/docker/docker, but to it seems to me that "components" may not include the "/" (or I missed how the "/" gets mangled). In conclusion, this means that "components" may only be placed at the top-level source directory. I guess what I can (should?) do is adjust the debian/copyright Files-Excluded field to exclude all entries but vendor/github.com/docker/docker, and use declare a 'vendor' component. Then I probably can use mk-origtargz to create both the "orig.tar.gz" as well as the "orig-vendor.tar.gz". That would, however, lead to a *very* elaborate Files-Excluded field. Does this make sense, or is there a simpler solution? The llvm-toolchain-7 example does not use gbp-buildpackage or pristine-tar. Instead they apparently have a script that generates all tarballs: https://sources.debian.org/src/llvm-toolchain-7/1:7.0.1-8/debian/orig-tar.sh/ I guess having a dedicated script such as this means not being able to use mk-origtargz. I would find that a bit unfortunate, because I'd hate this package to be a snowflake in the go-lang packaging team. Or do we already have similar snowflakes? what does the team think which approach is better? -rt On Fri, Mar 1, 2019 at 2:55 AM Simon McVittie wrote: > > You could consider using a multiple-.orig-tarball package in 3.0 > (quilt) format? See for example yquake2 (a relatively simple > example which bundles together https://github.com/yquake2/yquake2 and > https://github.com/yquake2/ctf) or llvm-toolchain-7 (a more elaborate > example with multiple subprojects). > > smcv > > -- regards, Reinhard
Re: Bug#923300: ITP: golang-github-openshift-imagebuilder -- Builds Dockerfile using the Docker client
On Thu, Feb 28, 2019 at 05:53:37PM -0500, Reinhard Tartler wrote: Description : Builds Dockerfile using the Docker client The short-description could use some improvement. It doesn't build Dockerfiles presumably, but container images, using Dockerfiles as the input. This is a build dependency of the buildah tool. I would love to see that (and podman) packaged in Debian. Thanks for working towards this. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Bug#923300: ITP: golang-github-openshift-imagebuilder -- Builds Dockerfile using the Docker client
On Thu, 28 Feb 2019 at 17:53:37 -0500, Reinhard Tartler wrote: > 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. I agree that this sounds like a de facto fork of the vendored library, more than a convenience code copy. > 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. You could consider using a multiple-.orig-tarball package in 3.0 (quilt) format? See for example yquake2 (a relatively simple example which bundles together https://github.com/yquake2/yquake2 and https://github.com/yquake2/ctf) or llvm-toolchain-7 (a more elaborate example with multiple subprojects). smcv
Bug#923300: ITP: golang-github-openshift-imagebuilder -- Builds Dockerfile using the Docker client
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * 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
