RFC: optional explicit mapping between orig component name and subdirectory

Simon Richter <[email protected]> Sun, 16 Nov 2025 11:56:00 +0900
Newsgroups gmane.linux.debian.devel.dpkg.general
Message-ID <[email protected]>
Hi,

I'd like to allow packages that have multiple source packages to unpack 
them to arbitrary directories in the source tree instead of a fixed 
mapping between the .orig archive name and the unpack directory.

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.

Because there would be (mostly) an 1:1 mapping between archives and 
submodules, each archive could be generated with git-archive, which 
gives them an embedded reference, which should make it really easy to 
scan the archive for potentially vulnerable vendored software, and at 
the same time, these archives are easily reproducible, as git-archive 
will recreate a bitwise identical stream when given the same parameters.

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?

    Simon