Re: [RFC v2 0/2] add kconfirm

[Miguel Ojeda]

On Sun, May 10, 2026 at 7:06 AM Jan Engelhardt <ej@xxxxxxx> wrote:
>
> Good lord, how is anyone supposed to review that amount –
> or is it just getting rubberstamped anyway?

Yeah, if one really wants to statically vendor the files, then please
follow the pattern we used for other vendoring: see the commits that
introduced e.g. `rust/syn/`.

In particular, we try to cut down there the dependencies and the files
within each dependency to those that are actually needed: no need to
support vendor optional dependencies that aren't used (and if they are
used, please try to see if they could be avoided), no need to support
all platforms (e.g. why do we need FreeBSD files here?), no need to
vendor the tests nor scripts, and so on.

For instance, for `syn`, I modified it (minimally) to cut down one
dependency. I also provided a script in the commit message to verify
the files are 1:1 identical to the ones upstream (before adapting them
with SPDX identifiers etc.).

So, from a quick look, here I see files like:

  scripts/kconfirm/vendor/vcpkg/test-data/normalized/installed/x86-windows/bin/freetype.dll

Which I would be surprised if they are needed.

In any case, when we discussed offline building in v1, that did not
necessarily mean vendoring every dependency manually into the tree,
but rather let the user set up the dependencies before (i.e.
connecting is fine) so that then the actual `make` steps can proceed
offline. For instance, using `cargo vendor`:

  https://doc.rust-lang.org/cargo/commands/cargo-vendor.html

In other words, one should be able to have users run a command or
similar, and then use the dependencies that are already downloaded.

By the way, another option for that may be using the distribution's
registry (e.g. Debian and Fedora provide one through the package
manager). That is even better (and we were requested to look into it
back then for `syn`), but it does introduce complications even if one
assumes Cargo is available (which we don't so far in the normal build
path), e.g. the versions need to fit, one still needs to provide a way
to do it for distributions that do not match, etc.

I hope that helps!

Cheers,
Miguel