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
