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
