Comments (4)
Your PRs seem correct at first glance, but it is problematic in two respects. For this reason, I have reverted these.
- If Cargo.lock is to be removed from gitignore, it should also be checked with cargo install --lock, which failed in the github workflow. These two change PR #61 and #64 should be handled in unified single PR, not separated.
- Normally it is expected to run cargo install cargo-generate-rpm, but Cargo.lock is not referenced by cargo install. When installing with reference to Cargo.lock, run cargo install --locked cargo- generate-rpm and you will need to run This is described at rust-lang/cargo#5654. Therefore, the behavior of both cargo install (without --locked) and cargo install --locked should be checked in test.
These points will need to be taken into account and redone.
from cargo-generate-rpm.
Alright, that makes sense. Can we clarify what is needed to be done to commit Cargo.lock
to the repository? Do you need a single PR for both #61 and #64? Do we need any additional changes in CI to test the behavior of cargo install
?
from cargo-generate-rpm.
This is only my thought that applies to my own project, if there are test and/or documentation changes in adding a feature, I would like them to be in one pull request (the commits can remain separated).
cargo install cargo-generate-rpm
installs the binary file built with the cargo build
(without --lock
) equivalent. cargo install cargo-generate-rpm --lock
installs ones with cargo build --lock
. Many people will (without thinking about difference) run it with the former. I do so, too. As of now, I couldn't decide if it is reasonable to test with cargo build --lock
only or not, taking that into account.
It is not always the case that the binary executable file package always includes the Cargo.lock file. For example, rust-lang/cargo does not add it. Since "cargo" is an official Rust tool, this does not mean "forgot to add Cargo.lock".
These may be common knowledge to those of you who develop Rust projects on a daily basis. However, your PR description is "too simplistic" for me, and I have many questions after doing my own research. Until these are resolved, I will not be merging this for a while.
from cargo-generate-rpm.
Personally, I usually commit Cargo.lock even for library crates. It somewhat helps with failures which originate from dependencies. Without it, CI may fail completely unrelated to a PR changes. And with binaries having Cargo.lock helps with reproducibility. It's a bit less concern for Cargo, since it's mainly distributed as pre-compiled binaries using rustup
as part of Rust toolchain.
from cargo-generate-rpm.
Related Issues (20)
- Add --separate-debug-symbols option similar to cargo deb HOT 1
- Out of date documentation on --auto-req options in readme HOT 1
- rpmlib(PayloadIsZstd) = 5.4.18-1 is needed HOT 2
- End of RPMv3 (e.g., centos7) support
- Unexpected behavior from --auto-req /path/to/find-requires
- Different metadata overwrite behavior than the document
- Can't run as cargo subcommand HOT 2
- Versions above 0.14.0 i.e. 0.14.1 and 0.15.0 dont work at all HOT 1
- using RPM macro scriptlets / BuildRequires HOT 2
- The `--set-metadata` option does not overwrite/set metadata anymore HOT 4
- Adding empty directories via %dir
- %files %dir and sections of rpm spec files HOT 1
- error: unpacking of archive failed on file /lib/systemd/system/xxx.service;6496c577: cpio: Digest mismatch HOT 3
- Feature Request: allow not replacing config files HOT 5
- RPM is not readable by rpmlint HOT 4
- Could not generate generate-rpm in case of --target specified HOT 2
- Failed dependencies: libc.so.6(GLIBC_2.29)(64bit) is needed when install generated .rpm package HOT 1
- Issue with generate RPM not matching the PowerPC64 LE architecture HOT 3
- [Feature-Request] Add `%pretrans %posttrans`? HOT 1
- Building rpm for `foo-bar` package means `foo-bar/Cargo.toml` must exists? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cargo-generate-rpm.