Re: [Buildroot] [PATCH 1/1] support/download: update rust package dependency resolving

From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: Afshin Pir <Afshin.Pir@gallagher.com>
Cc: "buildroot@buildroot.org" <buildroot@buildroot.org>,
	 Joseph Kogut <joseph.kogut@gmail.com>,
	David Pierret <david.pierret@smile.fr>,
	 Danilo Bargen <mail@dbrgn.ch>,
	Graeme Smecher <gsmecher@threespeedlogic.com>,
	 Torben Voltmer <mail@t-voltmer.net>,
	James Hilliard <james.hilliard1@gmail.com>,
	Manuel Diener <manuel.diener@oss.othermo.de>,
	Alexander Shirokov <shirokovalexs@gmail.com>,
	 Sam Voss <sam.voss@gmail.com>,
	Saeed Kazemi <kazemi.ms@gmail.com>,
	 Alex Michel <alex.michel@wiedemann-group.com>,
	Leo Yu-Chi Liang <ycliang@andestech.com>,
	 Christopher Obbard <obbardc@gmail.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	 Shubham Chakraborty <chakrabortyshubham66@gmail.com>
Subject: Re: [Buildroot] [PATCH 1/1] support/download: update rust package dependency resolving
Date: Fri, 18 Sep 2026 23:40:10 +0200	[thread overview]
Message-ID: <aq2uqSD7ynZ7y32B@windsurf> (raw)
In-Reply-To: <SY8PR01MB9238552908F7113FE349752194872@SY8PR01MB9238.ausprd01.prod.outlook.com>

Hello,

On Fri, Sep 18, 2026 at 09:25:21PM +0000, Afshin Pir wrote:

> 1- Regarding your concern about ‘make legal-info’, I believe my approach is not
> too much worse than what we have right now. Because right now when we run `make
> legal-info`, we won’t collect the real licenses for all dependencies.

Not completely correct. It is true that we don't list in <pkg>_LICENSE
the license of vendored dependencies and in <pkg>_LICENSE_FILES all
license files from vendored dependencies. However:

1. We could do that, because the vendored dependencies are in the tarball.

2. At least the source code of the vendored dependencies is in the
   tarball generated by make legal-info, and that includes the license
   files for all vendored dependencies.

So yes, what you propose is worse that what we have right now: your
approach as it is doesn't even include the source code of vendored
dependencies.

> I don’t believe we collect Licence files for all dependencies inside licenses
> folder of legal-info right now as well (at least I didn’t see anything in the
> build scripts to do that). But for the sources, it is true that we don’t have
> dependency sources inside legal-info folder with my approach. But it may be
> possible to just add the whole BR_CARGO_HOME folder as a compressed .tar.gz
> inside legal-info sources to address the issue.

Throwing the entire BR_CARGO_HOME means that it will include tons of
unrelated crates. Just if one day you built a Cargo package in
Buildroot, all its crates will be forever in BR_CARGO_HOME. It makes
the result quite a mess that isn't reproducible between machines, and
keeps on growing.

> 2- For the calculating hash of all collected dependency sources, your point is
> completely correct. But cargo already keeps checksum of each dependency source
> file inside ‘.cargo-checksum.json’ file inside fetched dependency. Whenever the
> dependency is going to be compiled, this checksum is validated again which
> prevents dependency source change. It is true that someone may go and change
> sources and update the checksum file alongside it, but this approach works with
> the vendored dependencies as well.

As I said in my previous reply, this was a weaker point. But having
the Buildroot hash validate the complete source code that serves as
build input is I believe a very valuable aspect of the current
approach.

> I completely agree with your points on the effects of my approach, but I’m not
> too sure about how concerning they are.

The first point is not "concerning", it just makes your proposed
approach unfortunately not acceptable at all, I'm afraid :/

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot