Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile
Helmut Grohne writes ("Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile"):
> Thank you very much for immediately taking this to the list.
You're welcome.
Thanks for the review and the penetrating questions.
> I think that you imply here that all of the rust libraries would be
> annotated <!cargo-upstream>. Do you confirm?
Yes.
> 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, this is not my intention. And IMO that increase would be
undesirable.
This facility is certainly cxompletely useless for a Rust library
package - those whose .debs are the Rust text and metadata, for
building other programs against. Those things don't even have "real"
Rust build-dependencies - the Rust build deps are just there for
testing etc. And there is no use to anyone building such a package if
they are using upstream crates.io packages.
So at the very least we're limiting this to leaf packages containing
binaries. And, probably even then, this will only be useful when the
Debian or upstream maintainers want this hybrid or stepping stone
workflow.
I was imagining that this would be done ad-hoc by a maintainer when
they had a reason to do it, not that it would be supported by even
every leaf package. In some cases it might be a transitional state.
I do think it would be useful for the central tooling to offer this
build profile for every package, but I don't think it is appropriate
to annotate all the Rust build depends for every package this way.
Tools like debcargo ought *not* to add this build profile to the Rust
deps.
If this profile turns out to be widely desired for "leaf packages at
random", filtering (or dummy-satisfying) the build dependencies should
be done some other way.
> 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?
They don't.
> 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?
As needed. No mass commit, no mass upload, no automated change.
> 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 think I'm sold on that name question.
> 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.
I don't have strong feelings about this. I chose "upstream" because
that seems to be the term of art that people working in this space
use, to distinguish the general public package repo, from the Debian
one.
> > 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.
I'm not sure precisely how this feature could (or should) be made
available to *all* application packages in a central way. Having
tools like debcargo automatically add the profile to the build deps
produces a lot of bloat. I'm hoping there is a better way.
But even without modifying the build dependencies, it is a lot easier
to cause a build to run without the stated build deps being satisfied,
than it is to do violence to the package build system.
This could be made easier. Maybe tools like sbuild could have a
sepaarate option to disregard build deps matching a wildcard pattern,
or something.
I am hoping to leave these considerations for the future.
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.
Reply to: