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
