Jonas Smedegaard writes ("Re: Proposed `cargo-upstream` dpkg-buildpackage etc.
build profile"):
> Similar pain for other upstream ecosystems as well - I know about npm
> for NodeJS modules, but imagine it is similar for Java and others as
> well.
Yes.
> What is the benefit of introducing a standardized flag for this
> relatively narrow scope, compared to doing non-standardized fetching of
> crates _before_ package build and building with those embedded?
> Example of doing that is here: https://salsa.debian.org/debian/helvum
> (essentially doing `cargo vendor --versioned-dirs debian/vendorlibs`).
IDK what precisely you mean there, and you've liked to the repo as a
whole so I'm not sure what to look for. Maybe you mean "what's wrong
with pretending to vendor the dependencies" ?
Whatever approach is taken, it has to be controlled somehow. For
example, the paths to dependencies need to be adjusted, or the use of
the Debian cargo wrapper enabled/disabled.
That control can be done by: (i) modifying the package source code
(which is much more a pain, even if it's a toggle in a single place),
(ii) ad-hoc environment variables or something (which don't survive
sbuild) or (iii) a build profile.
ISTM that this kind of "build this package in s funky way" situation
is precisely what build profiles are good for.
> If there is really a need for a standardized flag, then what is the
> benefit of a narrow one specific to cargo, compared to a more general
> "fetches-source-during-build" that would be suitable also for e.g.
> NodeJS fetching npm modules?
Wouter made the same point - I will reply there, to both the CC lists.
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.
