Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

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 <ijackson@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.