Re: RFC: optional explicit mapping between orig component name and subdirectory
Hi,
On 12/7/25 00:29, Guillem Jover wrote:
The nodejs packages were the bulk of orig addon tarball users I noticed
when scanning the archive, AFAIR. But I'd like to understand what
concrete benefit would we get by adding this backwards incompatible
feature, which could already be used right now (as I mentioned in my
other emails) by convention (just name the addon tarballs as say
"<source>.orig-vendor-node-<module-name>" and then changing dh-nodejs
to use that instead of the current patterns or adapting the files
listing the addons?
TBH I didn't expect that it was possible to do this with a patch, so the
next best thing I could come up with was to attach the symlinks to the
end of the main .orig archive, which would make this archive
unreproducible with git-archive alone (but at least reproducible with
Debian tools).
This would already be an improvement over the status quo where uscan
concatenates the archives (not sure if that leaves the comments), but
I'm seeing it as an intermediate step.
So a shorter-term plan might be to teach uscan to keep orig archives
separate when fetching submodules.
Notes:
- this would probably require debian/watch v5. Not a problem IMO.
- the watch file needs to explicitly enable this feature
- there should be a mapping from submodule name to orig tarball name
in the watch file
- in the first implementation, the patch file is generated from this
description
- ideally, there'd also be syntax for "discard this submodule" and a
mode where unhandled submodules are an error
- in addition, I think there should be a convention or policy for mapping
- my suggestion is to reserve "vendor-" as a namespace for vendored
dependencies, and to ask people to use these for anything that is likely
to pop up in the archive multiple times
- not sure if we should aim for consistent naming when the same
upstream project is vendored in multiple packages. Probably yes
- I expect that at some point someone will want to scan the archive
for anything named *.orig-vendor-*.tar.*, extract the git version
comment field and try to map this to a commit in a public repo, and then
it would be nice if they could easily map these to the upstream project.
- file-based vendoring (like typical uses of stb_image) are probably
out of scope, unless someone has an idea.
- I think the symlink farming will interact badly with patch
generation from dpkg-source --commit
All of the above can happen without dpkg changes.
Longer term, I think it would still be nice to have this information in
a machine-readable way that doesn't require scanning patches with a
heuristic, and that *does* need a dpkg (and Policy) change. The "RFC" in
the title is precisely because I understand it is backwards-incompatible
and would take several releases to introduce.
Also, the patch generation issue might need to be looked at
(transforming file names?).
My use case is the ngscopeclient package, which has submodules like
. .orig.tar.xz
lib .orig-lib.tar.xz
lib/imgui .orig-vendor-imgui.tar.xz
lib/imgui-node-editor .orig-vendor-imgui-node-editor.tar.xz
lib/logging .orig-logging.tar.xz
doc .orig-doc.tar.xz
The logging library is from the same author, and TTBOMK not used
anywhere else, so I wouldn't want to put it into the "vendor" namespace.
I think that from a requirements perspective, node packages are not that
different, but if there is something I'm missing, it would be good to be
aware of that early on.
I'm also not sure when I have time or energy for such a thing, so if
anyone wants to take over (warning: involves perl code), that's fine
with me as well.
Simon
Reply to: