Bruno Haible <br...@clisp.org> writes: > Simon Josefsson wrote: >> Finally, while this is somewhat gnulib specific, I think the practice >> goes beyond gnulib > > Yes, gnulib-tool for modules written in C is similar to > > * 'npm install' for JavaScript source code packages [1], > * 'cargo fetch' for Rust source code packages [2], > > except that gnulib-tool is simpler: it fetches from a single source location > only. > > How does Debian handle these kinds of source-code dependencies?
I don't know the details but I believe those commands are turned into local requests for source code, either vendored or previously packaged in Debian. No network access during builds. Same for Go packages, which I have some experience with, although for Go packages they lose the strict versioning so if Go package X declare a depedency on package Y version Z then on Debian it may build against version Z+1 or Z+2 which may in theory break and was not upstream's intended or supported configuration. We have a circular dependency situation for some core Go libraries in Debian right now due to this. I think fundamentally the shift that causes challenges for distributions may be dealing with packages dependencies that are version >= X to package dependencies that are version = X. If there is a desire to support that, some new patterns of the work flow is needed. Some package maintainers reject this approach and refuse to co-operate with those upstreams, but I'm not sure if this is a long-term winning strategy: it often just lead to useful projects not being available through distributions, and users suffers as a result. /Simon
signature.asc
Description: PGP signature
