Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile
Hi Ian,
Thank you very much for immediately taking this to the list. The
discussion I've seen thus far seems very constructive and useful to me.
Thanks to the other participants as well.
On Thu, Dec 15, 2022 at 10:41:13AM +0000, Ian Jackson wrote:
> I would like to add the following entry to the table of build
> profiles in BuildProfileSpec:
>
> Profile anme: `cargo-upstream`
> Can cause changes to built binaries, including functional chnges. (Y)
> Should not cause changes to set of build debs. (N)
> Description:
> Obtain Rust dependencies from crates.io, not from Debian; use a
> `Cargo.lock` from the source package if there is one. Will usually
> cause cargo to make network accesses. Ideally, behaviour of the
> resulting programs will be the same, but this is not guaranteed.
I think that you imply here that all of the rust libraries would be
annotated <!cargo-upstream>. Do you confirm?
Yes:
I caution that we increase our (uncompressed) sources by 200KB for
adding this. This assumes changing every package, but the scope
isn't entirely clear, see below. Do you confirm that this is the
intention and that you think this increase is fine?
No:
Would this profile show up in debian/control in any way? If not, why
use a build profile rather than an option?
(Please do skip questions that do not apply.)
Which packages should support this profile? I see the value for
applications. Do you also intend it for libraries? If yes, how do they
benefit?
How do you intend to transition packages to support this profile?
Should that happen on an as-needed basis? Should it happen as a mass
commit? Do you want it mass uploaded?
> This is useful when developing packages which are to be uploaded to
> Debian, but whose build dependencies are not yet available in the
> targeted suite.
Given all of the mails in the thread thus far, you've convinced me:
* That the requested feature is useful.
* That it should be ecosystem-specific.
* That it needs to be easy to use (and that build profiles satisfy this
requirement).
On the bike coloring front, I do prefer putting the package ecosystem
last (i.e. upstream-cargo > cargo-upstream) for the consistency reasons
that you gave in a reply.
I would also question the "upstream" part as it wasn't obvious to me
initially. Good alternatives that aren't too long are not easy to come
by, but maybe you have a reason to reject "external"? I think "external"
would more strongly highlight that a build is no longer self-contained.
In any case, I think the naming questions are solvable one way or
another, so please focus on the non-naming aspects first. I don't feel
too strongly about naming.
> However, this could be a generally useful feature for Debian's cargo
> tooling to support, and I think it could do so in a general way so
> that this profile would be available in most Debian packages
> containing Rust code, without package-specific work. Whether to
> implement such a feature is a matter for the maintainers of dh_cargo
> et al.; IMO the build profile registration is useful even ad-hoc,
> without any general feature.
Yeah, having this supported generically seems very useful. It would be
nice to have a supportive reply from one of the dh-cargo maintainers
here. (I do not see this as a requirement.)
I note that "without package-specific work" implies that you wouldn't
attach build profiles to Build-Depends, which was my initial question.
I'll stop second guessing here and wait for your answer.
Helmut
Reply to: