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
"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
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