Wouter Verhelst writes ("Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile"): > I have just one question: why make this rust-specific? I think a similar > thing might be useful for golang packages (who also don't support shared > libraries), or, heck, even Perl (if I'm willing to test that the package > works while I have the not-yet-packaged dependencies in my ~/perl5/lib)
You are absolutely right that many other upstream (language-specifc) package managers will have analogous situations. I think *each* of these should have their *own* build-profile, rather than one portmanteau one. If a package has both Rust and NPM build-dependencies, say, a user may very well want to use Rust dependencies from Debian and NPM dependencies from upstream, or vice versa. The profile name should be named after the upstream package manager being influenced, not after the programming language, since some languages have several. So I think that we will probably want cargo-upstream npm-upstream golang-upstream (is this the right name?) etc. Maybe this means that the name ought to be the other way arond, so they all group together in the table, like the `no*` options. upstream-cargo upstream-npm upstream-golang (is this the right name?) I don't want to speak for those working with these other package managers, so I don't propose to add all of those right away. But establishing the precedent will hopefulloy be helpful for them So for now I'm proposing to add just the cargo one. If someone working with Node packages (say) tells me "we want this for npm too" then great and we should do that right away. Otherwise we should wait until ti's wanted. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.