Spec URL: https://github.com/rhel-lightspeed/goose/blob/main/packaging/goose.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/@rhel-lightspeed/goose/fedora-43-x86_64/09793965-goose/goose-1.13.1-1.fc43.src.rpm Description: an open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM Fedora Account System Username: rolivier This is my first time trying to package something for fedora, and I would love to have a sponsor on this. I have some packaging experience, as I have been packaging other projects to RHEL in the past. Having goose in Fedora first will be a strategic win for my team at Red Hat (RHEL Lightspeed, https://github.com/rhel-lightspeed), as we are looking forward to bringing this to RHEL downstream in the near future, but we want to bring this to Fedora first and maintain a community around it.
https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_vendored_dependencies “In general, packages SHOULD NOT use bundled crate dependencies, whenever possible. “Whenever vendored / bundled crate dependencies are used (no matter which mechanism is used for the purpose), all bundled crate dependencies MUST be declared with virtual Provides in the format Provides: bundled(crate($crate)) = $version in the subpackage that contains the Rust component. For example, these virtual Provides are used to determine the impact of security vulnerabilities on packages that use vendored Rust dependencies. “Building exclusively from vendored dependencies by using a tarball that was generated by running cargo vendor SHOULD only be a last resort. […]” Is there a concrete technical reason for using vendored dependencies here? I know that RHEL vendors Rust dependencies as a matter of course, but this is Fedora. :-) I also see a lot of “CC0-1.0” in the license expression, which needs close investigation to make sure it’s for content and not for code (with very limited exceptions, https://gitlab.com/fedora/legal/fedora-license-data/-/blob/56aeba99ba1b551e82b359bde277d1c51cc26e13/data/CC0-1.0.toml#L11-L26), particularly because the vendored dependency bundle may be bringing in things that have never been packaged in Fedora before.
(In reply to Ben Beasley from comment #1) > https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/ > #_vendored_dependencies > > “In general, packages SHOULD NOT use bundled crate dependencies, whenever > possible. > > “Whenever vendored / bundled crate dependencies are used (no matter which > mechanism is used for the purpose), all bundled crate dependencies MUST be > declared with virtual Provides in the format Provides: > bundled(crate($crate)) = $version in the subpackage that contains the Rust > component. For example, these virtual Provides are used to determine the > impact of security vulnerabilities on packages that use vendored Rust > dependencies. > > “Building exclusively from vendored dependencies by using a tarball that was > generated by running cargo vendor SHOULD only be a last resort. […]” > > Is there a concrete technical reason for using vendored dependencies here? I > know that RHEL vendors Rust dependencies as a matter of course, but this is > Fedora. :-) > > I also see a lot of “CC0-1.0” in the license expression, which needs close > investigation to make sure it’s for content and not for code (with very > limited exceptions, > https://gitlab.com/fedora/legal/fedora-license-data/-/blob/ > 56aeba99ba1b551e82b359bde277d1c51cc26e13/data/CC0-1.0.toml#L11-L26), > particularly because the vendored dependency bundle may be bringing in > things that have never been packaged in Fedora before. Hi, Ben! I will double-check the vendored dependencies, that was a mistake on my part, sorry. I definitely think there are a couple of those that are indeed present in Fedora. Regarding the CC0-1.0 license, I will check as well.
Hi, Ben! I have spent the entire day yesterday trying to figure out the best way to explicit use dependencies coming from system package and the vendored ones, but I don't think this will quite work. If you know how can I instruct cargo to look for vendor sources, plus, the system packages one, I would love to try it out. I have asked the Rust SIG folks over the Red Hat slack, and the response I got was that this would not be possible at the moment, which is unfortunate. Regarding the CC0-1.0 license you mentioned, I'm still looking out to see if I can fix it. I've come down to this list of requirements, there is quite a lot that is packaged in fedora, but the fact that we still have dependencies that need to bundle, make this really hard to pull off during the rpm build. Also, during that analysis, it looks like there are some Windows dependencies getting in the mix, which is not useful here, so I will work with upstream to only require them if the target of building is Windows. If you're interested to see the efforts on how I got this list, this is my PR in upstream packaging for goose: https://github.com/rhel-lightspeed/goose/pull/6. # Rust dependencies BuildRequires: rust-ahash-devel BuildRequires: rust-anstream-devel BuildRequires: rust-anyhow-devel BuildRequires: rust-async-stream-devel BuildRequires: rust-async-trait-devel BuildRequires: rust-axum-devel BuildRequires: rust-base64-devel BuildRequires: rust-bat-devel BuildRequires: rust-blake3-devel BuildRequires: rust-bytes-devel BuildRequires: rust-chrono-devel BuildRequires: rust-clap-devel BuildRequires: rust-colored-devel BuildRequires: rust-config-devel BuildRequires: rust-console-devel BuildRequires: rust-ctor-devel BuildRequires: rust-dashmap-devel BuildRequires: rust-dirs-devel BuildRequires: rust-dotenvy-devel BuildRequires: rust-etcetera-devel BuildRequires: rust-fs2-devel BuildRequires: rust-futures-devel BuildRequires: rust-glob-devel BuildRequires: rust-http-devel BuildRequires: rust-http-body-util-devel BuildRequires: rust-hyper-devel BuildRequires: rust-ignore-devel BuildRequires: rust-image-devel BuildRequires: rust-include_dir-devel BuildRequires: rust-indexmap-devel BuildRequires: rust-indicatif-devel BuildRequires: rust-indoc-devel BuildRequires: rust-insta-devel BuildRequires: rust-is-terminal-devel BuildRequires: rust-jsonwebtoken-devel BuildRequires: rust-lazy_static-devel BuildRequires: rust-libc-devel BuildRequires: rust-lopdf-devel BuildRequires: rust-lru-devel BuildRequires: rust-minijinja-devel BuildRequires: rust-mockall-devel BuildRequires: rust-nanoid-devel BuildRequires: rust-nix-devel BuildRequires: rust-once_cell-devel BuildRequires: rust-open-devel BuildRequires: rust-paste-devel BuildRequires: rust-rand-devel BuildRequires: rust-rayon-devel BuildRequires: rust-regex-devel BuildRequires: rust-reqwest-devel BuildRequires: rust-rustyline-devel BuildRequires: rust-schemars-devel BuildRequires: rust-serde-devel BuildRequires: rust-serde_json-devel BuildRequires: rust-serde_path_to_error-devel BuildRequires: rust-serde_urlencoded-devel BuildRequires: rust-serde_with-devel BuildRequires: rust-serde_yaml-devel BuildRequires: rust-serial_test-devel BuildRequires: rust-sha2-devel BuildRequires: rust-shellexpand-devel BuildRequires: rust-shlex-devel BuildRequires: rust-sqlx-devel BuildRequires: rust-streaming-iterator-devel BuildRequires: rust-sys-info-devel BuildRequires: rust-sysinfo-devel BuildRequires: rust-tar-devel BuildRequires: rust-temp-env-devel BuildRequires: rust-tempfile-devel BuildRequires: rust-test-case-devel BuildRequires: rust-thiserror-devel BuildRequires: rust-tokio-devel BuildRequires: rust-tokio-stream-devel BuildRequires: rust-tokio-util-devel BuildRequires: rust-tonic-devel BuildRequires: rust-tower-devel BuildRequires: rust-tower-http-devel BuildRequires: rust-tracing-devel BuildRequires: rust-tracing-appender-devel BuildRequires: rust-tracing-subscriber-devel BuildRequires: rust-tree-sitter-devel BuildRequires: rust-tree-sitter-go-devel BuildRequires: rust-tree-sitter-java-devel BuildRequires: rust-tree-sitter-javascript-devel BuildRequires: rust-tree-sitter-python-devel BuildRequires: rust-tree-sitter-ruby-devel BuildRequires: rust-tree-sitter-rust-devel BuildRequires: rust-unicode-normalization-devel BuildRequires: rust-url-devel BuildRequires: rust-urlencoding-devel BuildRequires: rust-uuid-devel BuildRequires: rust-webbrowser-devel BuildRequires: rust-which-devel BuildRequires: rust-wiremock-devel BuildRequires: rust-zip-devel # End rust dependencies # Bundled dependencies Provides: bundled(crate(agent-client-protocol)) = 0.4.0 Provides: bundled(crate(aws-config)) = 1.5.18 Provides: bundled(crate(aws-sdk-bedrockruntime)) = 1.106.0 Provides: bundled(crate(aws-sdk-sagemakerruntime)) = 1.63.0 Provides: bundled(crate(aws-smithy-types)) = 1.3.2 Provides: bundled(crate(cliclack)) = 0.3.5 Provides: bundled(crate(criterion)) = 0.5.1 Provides: bundled(crate(devgen-tree-sitter-swift)) = 0.21.0 Provides: bundled(crate(docx-rs)) = 0.4.17 Provides: bundled(crate(jsonschema)) = 0.30.0 Provides: bundled(crate(keyring)) = 3.6.2 Provides: bundled(crate(mpatch)) = 0.2.0 Provides: bundled(crate(oauth2)) = 5.0.0 Provides: bundled(crate(opentelemetry)) = 0.27.1 Provides: bundled(crate(opentelemetry-appender-tracing)) = 0.27.0 Provides: bundled(crate(opentelemetry-otlp)) = 0.27.0 Provides: bundled(crate(opentelemetry_sdk)) = 0.27.1 Provides: bundled(crate(rmcp)) = 0.8.3 Provides: bundled(crate(tiktoken-rs)) = 0.6.0 Provides: bundled(crate(tokio-cron-scheduler)) = 0.14.0 Provides: bundled(crate(tracing-opentelemetry)) = 0.28.0 Provides: bundled(crate(tree-sitter-kotlin)) = 0.3.8 Provides: bundled(crate(umya-spreadsheet)) = 2.2.3 Provides: bundled(crate(utoipa)) = 4.2.3 Provides: bundled(crate(winapi)) = 0.3.9 Provides: bundled(crate(xcap)) = 0.0.14 # End bundled dependencies Thanks in advance!
Yes, it’s my understanding that it is not possible in general to mix vendored dependencies with separately-packaged ones, except in very limited cases like https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_replacing_git_dependencies. You shouldn’t be adding manual BuildRequires on rust-*-devel packages; all such dependencies should be handled with %cargo_generate_buildrequires, https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_dynamically_generated_buildrequires_for_crate_dependencies. You probably tried this because you were trying to find a way to mix vendored and system dependencies. > I've come down to this list of requirements, there is quite a lot that is packaged in fedora, but the fact that we still have dependencies that need to bundle, make this really hard to pull off during the rpm build. I’m curious why certain dependencies need to be bundled. Normally, when you need a crate that isn’t packaged, you’re expected to go package it. (You would be responsible for reviewing its contents if you shipped it in a vendor tarball anyway!) When a crate library is already in Fedora, but with an incompatible version, the answer may be to ask the maintainer to update it, patch the version bound in your Cargo.toml if possible, or in some cases create a compat package. > Also, during that analysis, it looks like there are some Windows dependencies getting in the mix, which is not useful here, so I will work with upstream to only require them if the target of building is Windows. That’s a good plan. You can also patch these out downstream for now. You can and should also patch out benchmark-only dev-dependencies like criterion.
Relaying Fabio Valentini’s opinion from the Fedora Rust channel on Matrix, > and in general, I think vendoring is "reasonable" if you end up needing to package > 20 new dependencies (But I’ll add that conversely, the more dependencies you vendor that are already separately packaged, the more burden of reviewing the contents and licensing of your dependencies, and perhaps patching some of them, falls solely on you rather than being shared with other maintainers.)
I don't think I have much to add to what Ben has already said here. Just some general comments: 1. It appears that the "new_cargo_macros" macro you define at the top of the spec file is unused. And I'm not sure what its purpose would even be? 2. The Summary and %description are not properly formatted - the Summary should be <80 characters long (so ... use something more concise than the current one) and the %description should be line-wrapped to <=72 characters per line. Maybe: "Summary: Extensible AI agent that goes beyond code suggestions" The fact that it's open source is a requirement for packaging for Fedora, you don't need to repeat that :) 3. It appears that you're using a tarball that contains "patched" sources, not the upstream ones. That's not how packaging is supposed to work - you should point the package at the upstream project's sources, and apply any patches you need to apply in packaging. ~~~ Also note that it *is* allowed to build with vendored Rust dependencies for Fedora - if packaging all missing dependencies would place an unreasonable burden on the packager. In this case, it looks like you have (at first glance) ~20 new dependencies that are not yet packaged for Fedora, which I would place to the more "unreasonable" end of that spectrum. However, it would be great to check *first* if you could actually trim that dependency tree to something more reasonable - for example, as Ben mentioned, by dropping Windows-specific, benchmarking-specific dependencies, or dependencies that are only needed for compiling example code. Another possibility is to check whether you some dependencies are pulled in by features that you don't even want or need, and to disable them too.
Hello, I do realize that this is possibly an old ticket. I am sorry that it hasn't been reviewed yet. Let me trigger the Fedora Review Service to see if the package builds successfully. Hopefully, a green check mark will attract some reviewer. If I am resurrecting an old ticket that you are not interested in anymore, my apologies, feel free to close it. [fedora-review-service-build]
Copr build: https://copr.fedorainfracloud.org/coprs/build/9820447 (failed) Build log: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2415364-goose/fedora-rawhide-x86_64/09820447-goose/builder-live.log.gz Please make sure the package builds successfully at least for Fedora Rawhide. - If the build failed for unrelated reasons (e.g. temporary network unavailability), please ignore it. - If the build failed because of missing BuildRequires, please make sure they are listed in the "Depends On" field --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
Copr build: https://copr.fedorainfracloud.org/coprs/build/9820274 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2415364-goose/fedora-rawhide-x86_64/09820274-goose/fedora-review/review.txt Found issues: - Not a valid SPDX expression '(Apache-2.0 OR MIT) AND BSD-3-Clause (MIT OR Apache-2.0) AND NCSA (MIT OR Apache-2.0) AND Unicode-3.0 0BSD OR MIT OR Apache-2.0 Apache-2.0 Apache-2.0 OR BSL-1.0 Apache-2.0 OR ISC OR MIT Apache-2.0 OR MIT Apache-2.0 WITH LLVM-exception Apache-2.0 WITH LLVM-exception OR Apache-2.0 OR MIT BSD-2-Clause BSD-2-Clause OR Apache-2.0 OR MIT BSD-3-Clause BSD-3-Clause AND MIT BSD-3-Clause OR MIT BSL-1.0 CC0-1.0 CC0-1.0 OR Apache-2.0 CC0-1.0 OR Apache-2.0 OR Apache-2.0 WITH LLVM-exception CC0-1.0 OR MIT-0 OR Apache-2.0 ISC ISC AND (Apache-2.0 OR ISC) ISC AND (Apache-2.0 OR ISC) AND OpenSSL LGPL-3.0-or-later MIT MIT AND BSD-3-Clause MIT OR Apache-2.0 MIT OR Apache-2.0 OR Zlib MIT OR Zlib OR Apache-2.0 MIT-0 MPL-2.0 Unicode-3.0 Unlicense OR MIT Zlib Zlib OR Apache-2.0 OR MIT'. Read more: https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1 Please know that there can be false-positives. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
Hi, Fabio and Ben! Thank you so much for the review, suggestions and feedback. I have talked with my team, and apparently, we don't require this package to be in Fedora anytime soon (our deadline will be around November of 2026). With that in mind, I take a step back and will try to package as much of the missing dependencies possible. I started this effort on my personal account, being the first one tracked in here: https://bugzilla.redhat.com/show_bug.cgi?id=2416340. Meanwhile, I will review the specfile for this package and adapt as you suggested. Since I'm new around here, is there any preferred state to put this ticket on? I can close it and re-open at a future date if it makes more sense. Thanks in advance!
(In reply to Rodolfo Olivieri from comment #10) > Since I'm new around here, is there any preferred state to put this ticket > on? I can close it and re-open at a future date if it makes more sense. Hmm, I’m not sure. If you aren’t planning to try to get this reviewed in the short term, closing and reopening would be fine (ideally linking this bug from the new one when you reopen). I suppose you could also repurpose a state like "MODIFIED" if you want to keep this bug open but don’t want it to show up in places like https://fedoraproject.org/PackageReviewStatus/reviewable.html. I’m not sure there is an agreed-upon standard approach in such cases.