Web lists-archives.com

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:
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 <smcv@xxxxxxxxxx> 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