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 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.
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.
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.
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`).
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?
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)
Jonas Smedegaard writes ("Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile"):
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.
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.
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.
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.
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.
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.
Thank you very much for immediately taking this to the list.
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?
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?
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.
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.
On Thu, Dec 15, 2022 at 11:44:34PM +0000, Ian Jackson wrote:...
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.
I think this becomes the crux of the matter. I see basically two
distinct ways to move forward:
What are your thoughts on updating Build-Depends?
B
In this case, the profile description should be more clear about the
intended scope (rust application packages).
I also do not see us automating the update to Build-Depends.
This could be made easier. Maybe tools like sbuild could have a
sepaarate option to disregard build deps matching a wildcard pattern,
or something.
The idea is good in principle. Let me do a brief excursion into
Multi-Arch for comparison. By default, we have an architecture
constraint on dependencies. It can be lifted either by M-A:foreign on
the target of the edge or by :any on the source of the edge. A build
profile is a bit like :any and annotates the source of an edge. Your
proposed wildcard pattern would be a target annotation for build
profiles in this analogy while the current profile implementation has no
way to do such target annotations.
This idea is also applicable beyond rust. With the nopython build
profile, we might want to automatically annotate Python dependencies. Unfortunately, we are now in a place where a significant portion of
packages uses Python modules during build (e.g. sphinx) while not
producing any Python modules or extensions as output. As such, we cannot mechanically tell how such a dependency is being used. Maybe a package
later contains a rust crate that is not shipped, but only used during
build. In this case, we wouldn't want to annotate the relevant
dependencies either.
So I think annotating rust Build-Depends has to be a semi-manual task at least. Updating dh-cargo or debcargo to automatically adapt its
behaviour still seems useful though as that reduces the amount of work
to updating Build-Depends.
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
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.
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.
I think this is a great idea.
In addition to the benefits you list (and less importantly, because
there's less direct affect on Debian), having this feature available would make it easier to create a first pass of a package of a Rust tool intended for local use. I often build semi-broken short-cut packages locally of things I need on some system but haven't yet found the time to make them properly ready for Debian, and then gradually finish the work to get them into Debian. It would be very useful to have this support to get over the initial barrier to making a Debian package.
I think it would increase the likelihood that I'd eventually do the work
to get all the way to an uploadable Debian package, whereas if it's
difficult to bootstrap from Cargo, I'm much more likely to let laziness
win, just build a static binary, and copy it around.
This is why I don't agree with Jonas: yes, there *are* other ways to
achieve the same goal, but they're more complicated and harder to explain. The user experience of this build profile looks a lot simpler and cleaner.
Quoting Russ Allbery (2022-12-15 17:41:15)
This is why I don't agree with Jonas: yes, there *are* other ways to
achieve the same goal, but they're more complicated and harder to
explain. The user experience of this build profile looks a lot simpler
and cleaner.
I don't have a firm opinion here, so wonder what you disagree with,
Russ.
For the record, prior to this thread Ian reached out to me privately
where we discussed my work on forking dh-cargo to behave more
"Debian-ish" than what is developed by the Rust team.
Perhaps this is a language thing: When I "question" Ians proposed
approach, I do not imply that I reject it or am against it, only that I
want to better understand it.
Jonas Smedegaard <jonas@jones.dk> writes:
Quoting Russ Allbery (2022-12-15 17:41:15)
This is why I don't agree with Jonas: yes, there *are* other ways to
achieve the same goal, but they're more complicated and harder to
explain. The user experience of this build profile looks a lot simpler
and cleaner.
I don't have a firm opinion here, so wonder what you disagree with,
Russ.
For the record, prior to this thread Ian reached out to me privately
where we discussed my work on forking dh-cargo to behave more
"Debian-ish" than what is developed by the Rust team.
Perhaps this is a language thing: When I "question" Ians proposed
approach, I do not imply that I reject it or am against it, only that I want to better understand it.
Oh, I'm sorry, this is probably just a sequence of misunderstandings. I think I misunderstood your message as being somewhat opposed, and then I think you read my "disagree" as stronger than I meant it. All I was
trying to say is that I think (based on my very sketchy understanding of build profiles) that this would have a lower bar of entry for building non-Debian packages as a stepping stone to proper Debian packages than pre-downloading the dependencies.
With nopython, we want to *avoid doing the Python things at all*. But
"the Python things" here isn't "all Python things" - it's "certain
Python things that appear in the outputs". So that can't be done as a blanket exclusion on B-d.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 163:47:36 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,513 |