rust2rpm -p
Enable a -p option in rust2rpm to activate a mode where:
-p
rust2rpm
Given a specific dependency to patch (e.g., fiat-crypto), it will locate the vendor directory and apply the patch to the existing Cargo structure. This will automate the manual process of: 1. Navigating to the unpacked sources directory 2. Running cargo vendor --versioned-dirs 3. Modifying the fiat-crypto crate 4. Repacking the tarball using tar -Jcvf vendor/ ../tarball.xz
fiat-crypto
cargo vendor --versioned-dirs
tar -Jcvf vendor/ ../tarball.xz
Additional options will be introduced to specify:
The corresponding patch file
If the operation fails:
Display an appropriate error message before quitting
If successful:
*.diff
This extends the rust -p behavior to handle not only RPM-based dependencies but also simple vendored dependencies, with options for specifying the dependency and patch file, automating the process in a straightforward manner.
rust -p
I've given this some thought, and I'm not sure that rust2rpm can (or should) accomodate every bespoke workflow here. It's already the most complicated piece of software that I've ever maintained, and the use case you're describing is very niche. To my knowledge, only 1-2 packages in Fedora use vendored sources and need to patch the contents of the vendor tarball.
Would something like this work for your use case instead:
--vendor
rust2rpm --vendor-myself
This would allow for maximum flexibility without needing to implement all of it in rust2rpm itself.
We could even provide some kind of separate helper program (rust2rpm-vendor, name TBD) to automate parts of this process so it would be scriptable:
rust2rpm-vendor
rust2rpm-vendor prepare
rust2rpm-vendor checksumfix
.cargo_checksum.json
rust2rpm-vendor compress
What do you think?
Metadata Update from @decathorpe: - Issue assigned to decathorpe - Issue set to the milestone: v27.0 - Issue tagged with: feature
Hi @decathorpe,
I think that could totally work for now. Having the ability to basically decouple the vendorfile from rust2rpm itself.
We can start by creating this ticket into the --vendor-myslef flag, which should be pretty much straightforward.
--vendor-myslef
Regarding the rust2rpm-vendor tool those steps are basically what I also had in mind. Would it be possible to also have that under pagure.io/rust2rpm or would you prefer to host it elsewhere?
Thanks!
I hope so. This ticket is already on list for the rust2rpm v27.0.0 milestone, so I'll get to it eventually.
It can be in this same repository, but I'd like it to provide a different CLI entry point. The current CLI interface already does many different things, and I'm trying to remove unrelated things rather than adding more :)
I've implemented part of this RFE in this commit: https://pagure.io/fedora-rust/rust2rpm/c/429b54b
The --vendor flag from rust2rpm ≤ v26 becomes an option with an argument in rust2rpm v27 - accepting values of off, auto, and manual, with
off
auto
manual
--vendor=off
--vendor=auto
--vendor=manual
The manual mode assumes usage of a vendor tarball (with the expected default name and folder structure) but does not actually create it.
This does not change the default behaviour (not passing --vendor works the same), and allows more control over rust2rpm behaviour in the non-default case.
With this, the parts that need to be implemented in rust2rpm directly are done - so I'm removing this from the v27 milestone. Other helper functionality for creating vendor tarballs can be implemented independently.
It would also be easy to add other modes in the future in a non-breaking way (for example, a "filtered" mode using cargo-vendor-filterer in a instead of plain "cargo vendor").
Metadata Update from @decathorpe: - Issue set to the milestone: None (was: v27.0)
Log in to comment on this ticket.