On Mon, Apr 8, 2024 at 6:17 AM Richard W.M. Jones <rjones@xxxxxxxxxx> wrote: > > On Fri, Apr 05, 2024 at 03:33:35PM +0200, Fabio Valentini wrote: > > On Fri, Apr 5, 2024 at 9:51 AM Michael J Gruber <mjg@xxxxxxxxxxxxxxxxx> wrote: > > > > > > So you're saying that those packages are in the repos for everyone but > > > not meant to be installed by anyone (besides mock chroots), and that is > > > how and why they are packaged. > > > > Yes. That is the best we can do given how cargo + Rust work. > > > > > `This package contains library source intended for building other packages which > > > use the "xyz" crate.` > > > > So the description matches what I said? > > > > > Unless you `fedpkg local` build it. Or maybe only if you `fedpkg > > > mockbuild` it. Does a rebuild from `fedpkg srpm` even work? > > > > > > Wow! > > > > Sorry to burst your bubble, but "fedpkg local" is an ugly hack > > (independent of Rust peculiarities). > > fedpkg local works fine for almost all cases. > > > And I am not interested in adding workarounds to the Rust packaging > > toolchain to support it. > > > > "fedpkg mockbuild" and "fedpkg srpm" all work as expected ... > > > > > Is there any other set of packages which we package like that? > > > > Probably golang ... maybe Haskell, OCaml? > > OCaml is definitely _not_ packaged like this. ocaml-* and > ocaml-*-devel packages are normal packages that can be installed by > end users if they want, although usually only if they're developing > OCaml software. > Packaged Rust crates work *fine* for local development as long as you are willing to cut yourself off from crates.io. Unlike *every other language package manager*, Cargo does not support multiple concurrent indexes. This is ultimately the bottleneck, and there's been very little interest in resolving this upstream. Upstream issue: https://github.com/rust-lang/cargo/issues/4883 Without this feature, it becomes difficult to do development using packaged crates. -- 真実はいつも一つ!/ Always, there's only one truth! -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue