[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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





Le sam. 6 déc. 2025 à 10:48, Bastien Roucaries <rouca@debian.org> a écrit :
Le dimanche 16 novembre 2025, 03:56:00 heure normale d’Europe centrale Simon Richter a écrit :
> 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.
_javascript_ will love to get this

rouca
>
> 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?

Fantastic, this is a missing feature of components.

How will git-buildpackage deal with this ? Currently we need to explicitely set
component = ['xxx']
and I suppose gbp import-orig will need to be adapted as well.


Reply to: