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 <s...@debian.org> 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
