Firstyear
commented
3 years ago Hey mate, glad to hear your using cargo-vendor,
I don't think this is a problem with cargo-vendor specifically - it sounds like the culprit is the lack of the lock file.
Let's imagine your _service file is similar to the example https://en.opensuse.org/Packaging_Rust_Software
<services>
<service mode="disabled" name="obs_scm">
<service mode="disabled" name="tar" />
<service mode="disabled" name="recompress">
<service mode="disabled" name="set_version"/>
<service name="cargo_audit" mode="disabled">
<service name="cargo_vendor" mode="disabled">
</services>Let's focus on the order of these modules.
When you first run osc service ra, you get a clone of the source into projectname. This is then compressed into projectname.tar.xz. This initial checkout does NOT have a Cargo.lock file.
Then later in the process, you run cargo_vendor. Since this generates the Cargo.lock, it now creates packagename/Cargo.lock. But remember, this doesn't cause the the projectname.tar.xz to be updated, which still is MISSING the Cargo.lock.
Then you do your build - it fails, because you can't generate a Cargo.lock in --offline.
So you re-run the osc service. What happens is you already hae a checkout of projectname and it now also contains the Cargo.lock file that was generated by the previous executions cargo_vendor call. This is re-compressed to projectname.tar.xz now containing Cargo.lock, so your subsequent build works.
Honestly, I think this is an artifact of how the module order is processed, and Ithink it's a potentially good reason to update and change the examples and how we present them.
I think if we change the example _service to:
<services>
<service mode="disabled" name="obs_scm">
<service name="cargo_audit" mode="disabled">
<service name="cargo_vendor" mode="disabled">
<service mode="disabled" name="tar" />
<service mode="disabled" name="recompress">
<service mode="disabled" name="set_version"/>
</services>This should mean the Cargo.lock is created before you call tar.
A serious issue though, is if we cleanup the projectname/vendor folder - if we aren't, then we are effectively double vendoring here in this process, so I think we should check that.
Additionally, if this application is a binary, it's a recomendadiotn from rust as a language that it should commit it's Cargo.lock, so you could also ask upstream to consider commiting that, at least into their release tags.
Does that help?
glaubitz
I have been using
obs-service-cargo_vendorfor the first time this week and I ran into the problem that vendoring didn't work correctly on the first attempt withcargobeing unable to find the vendored sources during build. I was able to fix the problem by just runningosc service raa second time.Trying to build the package after the first call to
osc service rafails withcargobeing unable to find the vendored sources:Just re-running
osc service rafixes the problem: