Re: [RFC PATCH] docs: build-platforms: refine requirements on Python build dependencies

[Paolo Bonzini]

On 2/17/23 16:29, Daniel P. Berrangé wrote:
> > * it introduces different support periods for*native*  vs.*non-native*
> >    dependencies.  Non-native dependencies are currently Python ones only,
> >    and for simplicity the policy only mentions Python; however, the concept
> >    generalizes to other languages with a well-known upstream package
> >    manager, that users of older distributions can fetch dependencies from;
>
> I guess this would mean its applicable to perl/ruby/etc, but really
> we should be exclusively using Python for our scripting needs, except
> for legacy stuff we already have. So in practice non-native == python.

Yeah, we used to have some Perl but it was always pretty basic in terms 
of dependencies.

> Potentially if we want to use Rust, we'd want vendoring of deps needed
> by Rust code, and that's native deps arguably, rather than non-native.

Indeed I was thinking more of Rust/Go than Perl or Ruby.  Distros 
generally don't try to include all possible Rust and Go dependencies or 
to build all Rust/Go packages with a single version of a dependency. 
LWN has had plenty of articles over the years about Debian and Fedora's 
failed attempts to do so.

So I considered those to be non-native dependencies in the sense of 
dependencies that can be fetched by a "non-native" package manager, i.e. 
one that is not rpm- or deb-based.

I'm not sure whether we would vendor the dependencies or download them 
at configure time, but anyway they would probably be vendored in the 
release tarball only, similar to submodules.

Paolo