Re: RFC: optional explicit mapping between orig component name and subdirectory

[Guillem Jover <guillem@debian.org>]

Hi!

On Sun, 2025-11-16 at 11:56:00 +0900, Simon Richter wrote:
> The main use case would be orig archives that need to go into a
> subdirectory -- we can't use a name like foo_1.orig-sub/dir.tar.xz
> for obvious reasons. There are a few packages that use Git
> submodules in this way, and I'd like to translate the submodules to
> separate orig archives.

> The main benefit I see would be that this would allow me to make it
> more visible that this package contains a vendored copy of imgui
> (and a few others). Ideally, I'd like to do something like
> 
>     /                 .orig.tar.xz
>     /lib              .orig-lib.tar.xz
>     /lib/imgui        .orig-vendor-imgui.xz
>
> and, over time, turn it into a policy that vendored libraries should
> go into ".orig-vendor-*" archives so they can be easily scanned for.

So I guess there are two parts to this proposal. One is a matter of
convention in how to name the addon tarballs, which can be done
already right now. The other is the remapping into subdirs, which
can also be done somehow declaratively already, by adding a git
formatted patch, with either a symlink doing the redirection (or
with a more heavy weight «git mv» but that operates per file which
would cause major conflicts over time and does not seem maintainable).

> For this, I'd like to add an extension to the dsc format to allow
> overriding the unpack location for an .orig archive. If no override
> is given, the old mapping would still apply (in the ngscopeclient
> case, "lib" is just a normal subproject that's not vendored, and it
> goes into a toplevel directory).

> Opinions?

I guess after skimming over the archive for the majority of addon
tarball users, I don't think I've seen much of a need for this
remapping support (to be clear not denying there is going to be
cases where it applies, it just feels like that might be a minor
set?), and I'm not thrilled about adding such extension that is going
to be backwards incompatible.

Isn't the git formatted patch adding a symlink a viable option that
works today?

Thanks,
Guillem