Problem: The problem I want to have a helper function: After having done a libressl update, I wanted to emerge net-news/newsboat. That ebuild errors out with the info that the crate openssl-sys-0.9.58 doesn't support my openssl version. I am able to search at: https://crates.io/search?q=openssl-sys and I find there is an update, I can easily edit the newsboat ebuild with changing to openssl-sys-0.9.59 and the command ebuild newsboat-2.21-r1.ebuild manifest successfully download the crate and updates the file net-news/newsboat/Manifest But while emerge it errors out. There are files that must be patched: work/newsboat-2.21/Cargo.lock work/newsboat-2.21/rust/libnewsboat/Cargo.toml with the new version number and a new sha256sum. Solution: How about a helper function in the cargo.eclass to use in the ebuild like --- CRATEUPDATE=( Cargo.lock rust/libnewsboat/Cargo.toml ) src_prepare() { crateupdate openssl-sys libz-sys curl-sys } --- where CRATEUPDATE hold all files in the source to patch with the crate version number given in the ebuild. ... And the changed sha256sum patched also Ok, a heavy weight new function for the cargo.eclass ... Reproducible: Always
Such a new function crateupdate in eclass/cargo.eclass would obsolete the file: net-news/newsboat/files/newsboat-2.20.1-libressl.patch which is a patch used in: net-news/newsboat-2.21-r1.ebuild
sorry! patch used in older version: newsboat-2.20.1.ebuild
In my case patching just Cargo.lock worked --- a/Cargo.lock 2020-09-20 21:14:02.000000000 +0200 +++ b/Cargo.lock 2020-12-14 20:39:17.755939043 +0100 @@ -110,7 +110,7 @@ "cc 1.0.57 (registry+https://github.com/rust-lang/crates.io-index)", "libc 0.2.77 (registry+https://github.com/rust-lang/crates.io-index)", "libz-sys 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)", - "openssl-sys 0.9.58 (registry+https://github.com/rust-lang/crates.io-index)", + "openssl-sys 0.9.59 (registry+https://github.com/rust-lang/crates.io-index)", "pkg-config 0.3.17 (registry+https://github.com/rust-lang/crates.io-index)", "vcpkg 0.2.10 (registry+https://github.com/rust-lang/crates.io-index)", "winapi 0.3.9 (registry+https://github.com/rust-lang/crates.io-index)", @@ -339,7 +339,7 @@ [[package]] name = "openssl-sys" -version = "0.9.58" +version = "0.9.59" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "autocfg 1.0.0 (registry+https://github.com/rust-lang/crates.io-index)", @@ -672,7 +672,7 @@ "checksum objc_id 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "c92d4ddb4bd7b50d730c215ff871754d0da6b2178849f8a2a2ab69712d0c073b" "checksum object 0.20.0 (registry+https://github.com/rust-lang/crates.io-index)" = "1ab52be62400ca80aa00285d25253d7f7c437b7375c4de678f5405d3afe82ca5" "checksum once_cell 1.4.1 (registry+https://github.com/rust-lang/crates.io-index)" = "260e51e7efe62b592207e9e13a68e43692a7a279171d6ba57abd208bf23645ad" -"checksum openssl-sys 0.9.58 (registry+https://github.com/rust-lang/crates.io-index)" = "a842db4709b604f0fe5d1170ae3565899be2ad3d9cbc72dedc789ac0511f78de" +"checksum openssl-sys 0.9.59 (registry+https://github.com/rust-lang/crates.io-index)" = "de52d8eabd217311538a39bba130d7dea1f1e118010fee7a033d966845e7d5fe" "checksum percent-encoding 2.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "d4fd5641d01c8f18a23da7b6fe29298ff4b55afcccdf78973b24cf3175fee32e" "checksum pkg-config 0.3.17 (registry+https://github.com/rust-lang/crates.io-index)" = "05da548ad6865900e60eaba7f589cc0783590a92e940c26953ff81ddbab2d677" "checksum ppv-lite86 0.2.8 (registry+https://github.com/rust-lang/crates.io-index)" = "237a5ed80e274dbc66f86bd59c1e25edc039660be53194b5fe0a482e0f2612ea"
Ionen mentioned this again the other day after I was suffering trying to update all the sequoia packages and made a good suggestion. We can just copy the interface for GIT_CRATES w/ just a CRATES_PATCH=( foo-1.2.3 ... ). The nice thing is we don't need to substitute the old one because of how Cargo patching works, just add in the new one. May want to have the responsibility be on the ebuild author to update CRATES but we could go the other direction for that too. Guess it works better to need a manual CRATES update if want to call conditionally in src_prepare or similar, or could just have a global-scope helper and a different phase-level one. Dunno.
We discussed it with mgorny before while working on one of his cases for pycargoebuild, we don't really need to update anything manually - cargo can do it for us since version 1.53 basically we need to do 2 things: 1) Update crate in question in CRATES (and deps if appropriate, out of scope here) 2) Run cargo update before build. Because cargo registry access is prohibited, cargo will only look in offline registry eclass prepared, and will pick those crates. Cargo can update ALL crates with newer versions. Or, alternatively, cargo update can get an argument to specify which exactly crate to update. for example > cargo update - updates all crates that match dep constraints found in offline registry. - this way we only have to make sure CRATES contains updated entries. may be hard to track unless someone mentions that CRATES entry contains a bumped crate. > cargo update foo - updates only foo crate. - can be triggered by a special variable. For example UPDATE_CRATES=( foo ). - still requires adding UPDATE_CRATES to CRATES, because src_uri and unpack purposes. I've been telling interested parties to just update crate in CRATES and run "cargo update || die" before build, after src_prepare. fine-grained control seems a bit overkill right now but might come in handy in multi-crate workspaces where you only want to update single dep without updating others. I think running it unconditionally has pros and cons though. So my last idea was introducing an eclass variable (like CARGO_UPDATE_CRATES=1) which if not empty and equals 1 triggers cargo update, and if an array - passes each array member as a package spec to cargo update. that seems like safest solution that covers 99% usecases.