cat-in-136/cargo-generate-rpm

Cargo helper command to generate a binary RPM package

cargo-generate-rpm's Issues

rpmlint warnings

Hi,

When I run rpmlint on my generated RPM I get some warnings which I think I have no control over as they refer to missing spec fields that are not generated by cargo-generate-rpm, e.g.:

• routinator.x86_64: W: manpage-not-compressed gz /usr/share/man/man1/routinator.1

It's a bit ugly to either store the man page compressed in my Git repo. I could compress it before invoking cargo generate-rpm, but as cargo-generate-rpm is aware of "doc" assets perhaps it could compress it for me?

• routinator.x86_64: E: no-buildhost-tag
• routinator.x86_64: E: no-changelogname-tag
• routinator.x86_64: W: no-url-tag

Unless I am mistaken I see no way to provide these via the Cargo.toml syntax supported by cargo-generate-rpm.

• routinator.x86_64: E: no-binary

Do you have any idea why even though I have binary assets installed to /usr/bin/ it complains that I do not have a binary?

• routinator.x86_64: W: conffile-without-noreplace-flag /etc/routinator/routinator.conf

I assume this refers to some setting that I have no control over?

Thanks,

Ximon

using glob pattern in workspace

Hello,
I think there is a bug when using glob pattern in assets in combination with a workspace project.

When I use this assets:

...
{ source = "../public/**/*", dest = "/usr/share/ffplayout/public/", mode = "644" },
...

and run cargo generate-rpm --target=x86_64-unknown-linux-musl -p ffplayout-engine -o ffplayout-0.12.0-1.x86_64.rpm, the public folder get ignored. Only when I cd into ffplayout-engine and run the generation without a project flag it works like it should.

Issue with generate RPM not matching the PowerPC64 LE architecture

Impacted version

0.12.1

System

• Fedora 39 (6.5.0 ppc64le kernel)
• Hardware: Raptor Computing Blackbird with IBM POWER9 Sforza CPU

Steps to reproduce

# I am trying to build amdgpu_top package
$ git clone https://github.com/Umio-Yasuno/amdgpu_top
$ cd amdgpu_top
$ cargo install --locked --path . --no-default-features --features="tui"
$ cargo build --release --target powerpc64le-unknown-linux-gnu # target ppc64le architecture
$ file ./target/release/amdgpu_top 
./target/release/amdgpu_top: ELF 64-bit LSB pie executable, 64-bit PowerPC or cisco 7500, OpenPOWER ELF V2 ABI, version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.2, BuildID[sha1]=a6b0d839eb4db3d50d33cb9eb25f58723f00d224, for GNU/Linux 3.10.0, stripped
# Looks good ^ the binary is great and working
# let's try to package it
# firstly all config can be found in https://github.com/Umio-Yasuno/amdgpu_top/blob/main/Cargo.toml#L51
$ cargo generate-rpm --target powerpc64le-unknown-linux-gnu -a ppc64le
# let's try to install it
$ sudo rpm -i target/powerpc64le-unknown-linux-gnu/generate-rpm/amdgpu_top-0.2.0-1.powerpc64le.rpm 
# got error
#	package amdgpu_top-0:0.2.0-1.powerpc64le is intended for a different architecture
# let's double check the RPM one more time
$ sudo rpm -qip target/powerpc64le-unknown-linux-gnu/generate-rpm/amdgpu_top-0.2.0-1.powerpc64le.rpm 
Name        : amdgpu_top
Epoch       : 0
Version     : 0.2.0
Release     : 1
Architecture: powerpc64le
Install Date: (not installed)
Group       : Unspecified
Size        : 13658190
License     : MIT
Signature   : (none)
Source RPM  : (none)
Build Date  : Sat 02 Sep 2023 17:31:33
Build Host  : (none)
URL         : https://github.com/Umio-Yasuno/amdgpu_top
Summary     : Tool to displays AMDGPU usage.
The tool displays information gathered from performance counters (GRBM, GRBM2), sensors, fdinfo, gpu_metrics and AMDGPU driver.

Description :
Tool to displays AMDGPU usage.
The tool displays information gathered from performance counters (GRBM, GRBM2), sensors, fdinfo, gpu_metrics and AMDGPU driver.

Unsure if it is the fault of cargo-generate-rpm or rpm itself?

Feature request: Support directories with --output

Add support for --output argument values that end in / ala cargo-deb.

Without this if I wish to generate the RPM file in a different output directory I also have to either lose the detals contained in the generated file name (e.g. routinator-0.10.0-dev-1.x86_64.rpm) or do extra work to try and mimic that file name structure myself.

Looking at the code it seems that this would require some minor changes to main::process(), if I get time I'll try to submit a PR.

RPM is not readable by rpmlint

A RPM created with cargo generate-rpm is installable, but cannot be investigated with rpmlint.

$ rpmlint target/generate-rpm/hello-world-0.1.0-1.x86_64.rpm 
(none): E: fatal error while reading target/generate-rpm/hello-world-0.1.0-1.x86_64.rpm: list index out of range

With verbose output, the following is printed:

$ rpmlint -v target/generate-rpm/hello-world-0.1.0-1.x86_64.rpm 
files over 4GB not supported by cpio, use rpm2archive instead
cpio: premature end of archive
(none): E: fatal error while reading target/generate-rpm/hello-world-0.1.0-1.x86_64.rpm: list index out of range
Traceback (most recent call last):
  File "/bin/rpmlint", line 8, in <module>
    sys.exit(lint())
             ^^^^^^
  File "/usr/lib/python3.11/site-packages/rpmlint/cli.py", line 177, in lint
    sys.exit(lint.run())
             ^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/rpmlint/lint.py", line 105, in run
    return self._run()
           ^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/rpmlint/lint.py", line 76, in _run
    self.validate_files(self.options['rpmfile'])
  File "/usr/lib/python3.11/site-packages/rpmlint/lint.py", line 237, in validate_files
    self.validate_file(pkg, pkg == packages[-1])
  File "/usr/lib/python3.11/site-packages/rpmlint/lint.py", line 261, in validate_file
    raise e
  File "/usr/lib/python3.11/site-packages/rpmlint/lint.py", line 251, in validate_file
    with Pkg(pname, self.config.configuration['ExtractDir'],
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/rpmlint/pkg.py", line 423, in __init__
    self.files = self._gather_files_info()
                 ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/rpmlint/pkg.py", line 576, in _gather_files_info
    pkgfile.size = sizes[idx]
                   ~~~~~^^^^^
IndexError: list index out of range

---

To reproduce:
Create a new project using cargo new hello-world. Then adjust the Cargo.toml like this:

[package]
name = "hello-world"
version = "0.1.0"
edition = "2021"
authors = ["Cargo"]
description = "A hello-world program"
license = "MIT"
homepage = "https://my-hello-world.com"
repository = "https://github.com/fake/hello-world"

[package.metadata.generate-rpm]
assets = [
    { source = "target/release/hello-world", dest = "/usr/bin/hello-world", mode = "755" }
]

Finally generate the RPM and try to lint it with rpmlint.

Or am I'm doing something wrong here?

---

Environment:

• Fedora 38
• cargo 1.70.0 (ec8a8a0ca 2023-04-25)
• cargo-generate-rpm 0.11.1

Unable to use custom rpm package version

We have custom package version format, for example: 3.0.A.1 ...when adding this version into Cargo.toml version field:

[package]
version = "3.0.A.1"

this will fail with:

Caused by:
unexpected character 'A' while parsing patch version number for key package.version

The same is happening when building DEBIAN package with cargo-deb BUT cargo-deb has special option that can be used to pass in any custom version:

cargo deb --deb-version 3.0.A.1 # this one works for DEBIAN packages

Could you please create a workaround for this, so any custom version format can be used, perhaps similar behavior (cmdline option) as cargo-deb tool has?

Thank you very much

Error `cpio: Bad magic' with v0.5.0 when doing yum install on Centos 7

See: https://github.com/NLnetLabs/krill/runs/4803590475?check_suite_focus=true#step:12:48

This seems to be caused by the new LZMA payload compression as using the new undocumented (in the README at least) command line switch --payload-compress zip solved the problem.

It might be an idea to document in the README that for older O/S's you might need to use --payload gzip.

Missing Cargo.lock

Cargo.lock should be committed to the repository since this is a binary application.

cargo-generate-rpm/.gitignore

Lines 152 to 154 in 346e1fe

	# Remove Cargo.lock from gitignore if creating an executable, leave it for libraries
	# More information here https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html
	Cargo.lock

Support custom and auto requires

Hi,

I need to specify a require when building an RPM but, unless I missed something, to do that with this crate I have to fork the crate and invoke requires myself, e.g.:

builder = builder.requires(rpm::Dependency::eq("openssl-libs", "1:1.1.1g-12.el8_3"));

It occurs to me that the cargo-deb crate supports specification of Deb package dependencies in Cargo.toml, and has Rust code for invoking ldd and dpkg -S (disclaimer: I use cargo-deb and contributed to it as well) to identify the packages the built binaries depend on and for using those if the user specifies either no dependencies or includes "$auto" in the list of dependencies.

Thus I would like a way to specify dependencies myself in the Cargo.toml file ala cargo-deb, and even better the $auto depends functionality too. For RPMs that could be done with parsing the output of ldd and then using rpm -qf </path/to/lib> to work out the package that provides the lib.

Is this of interest? Would you be open to a pull request? I could check with the author of cargo-deb if he minds code being copied from that project and modified for use here. Alternatively, and I'm dubious about the benefits of this, perhaps looking further ahead if there is sufficient commonality between this project and cargo-deb there could be a way to share code (factor out common elements to a support crate?) or combine the projects even (not sure that is wise, logic added for RPMs might have unintended consequences for DEB packaging or vice versa, automated testing would have to be quite thorough to avoid such inadvertent mistakes).

Ximon

mc cannot read resulting rpm file

The Midnight Commander (mc) tool is nice for inspecting RPM files. Unfortunately, for some reason, mc cannot open the RPM files resulting from "cargo generate-rpm". mc writes a number of error messages like "Cannot parse: -r--r--r-- 1 root root 495 e) HEADER", see attached screenshot:

Attached is also some code which can be used to reproduce the issue: genrpm.tar.gz

Perhaps generate-rpm is not be producing metadata which mc needs? Some may see this as an issue in mc, but there could be other RPM-related tools which will also trip over this, hence this ticket.
The related mc code seems to be this script, but I don't see anything obviously wrong in it: https://github.com/MidnightCommander/mc/blob/master/src/vfs/extfs/helpers/rpm

Feature Request: allow not replacing config files

would be cool if there was a way to specify %config(noreplace) so that configuration files will not be automatically be replaced (and renamed .rpmsave) during updates by default.

Cannot publish to crates.io by git+rev dependency of PR #23

In PR #23 and issue #21, git+rev dependency was added to Cargo.toml but it is not acceptable for publishing to crates.io.

$ cargo publish --dry-run
    Updating crates.io index
error: all dependencies must have a version specified when publishing.
dependency `rpm-rs` does not specify a version
Note: The published dependency will use the version from crates.io,
the `git` specification will be removed from the dependency declaration.

Error raised on workspace inheritance of `package.edition`

"value from workspace hasn't been set" error raised when workspace inheritance is used and its toml has package.edition.

#44 (comment)

@cat-in-136 Did some testing. When I use the workspace for the version / license it works fine. But adding the edition, will result in the above error. First gut feeling is that somethings is going wrong in the toml_edit lib, as the generate-rpm code is not using the edition field. That would suggest things go wrong on line 73: manifest.inherit_workspace(&workspace_manifest, p.as_ref())?;, some context to the errors would help.

It is caused by the cargo_toml bug https://gitlab.com/crates.rs/cargo_toml/-/issues/20

Install different files for different targets

Hi,

How would I use cargo generate-rpm to install a different systemd service file on an older RHEL/CentOS release than on a newer release? For comparison, with cargo deb I used the "variants" support in Cargo.toml to define different assets to install in different "variants".

Thanks,

Ximon

Support for rpm file which does not have a dependency on /bin/sh

All RPMs generated by cargo-generate-rpm require /bin/sh.

This seems unnecessary, as Rust binaries don't universally require a shell. In my case I'm trying to build distroless-like containers from RPMs generated by cargo-generate-rpm, and this is causing a shell and it's dependencies to be pulled in unnecessarily.

This behaviour comes from by rpm-rs, which appears to not be maintained at present: Richterrettich/rpm-rs#54. I've raised a PR to rpm-rs/rpm#7 - which is a community fork that isn't yet publishing to crates-io.

Handling RC versions

Hi,

RPM package versioning policy supports the tilda character to denote a pre-release version. However, Cargo.toml doesn't permit a tilda in the version string.

With cargo-deb we have the same issue for DEB packaging policy but we pass the version in as a --dev-version command line argument when running cargo deb. With cargo generate-rpm I have to hack the Cargo.toml file after I have run cargo build but before I run cargo generate-rpm so that I can replace -rcN with ~rcN.

Do you have any better suggestions on how to handle this scenario?

Thanks,

Ximon

Using `-ih` on Centos7 causes many hash marks and a locked RPM db

This only happens on centos 7 afaict.

Steps to reproduce:

1. git clone https://github.com/cat-in-136/cargo-generate-rpm.git
2. cd cargo-generate-rpm
3. cargo install --path .
4. cargo build --release
5. cargo strip -s target/release/cargo-generate-rpm
6. cargo generate-rpm --payload-compress none --auto-req no
7. docker run --rm -v $PWD:/workdir centos:7 rpm -ih /workdir/target/generate-rpm/cargo-generate-rpm-0.6.0-1.x86_64.rpm

Adding -i -t to the above docker run command will produce infinite hashmarks and lock the rpm db

I tested using almalinux:8, centos:6, and centos:8 and they all function as expected. I'm pretty sure this is an issue with centos 7 itself, but users of the library should be aware of this issue.

[Feature-Request] Add `%pretrans %posttrans`?

When RPM upgrades a package it will run all the post/pre install scripts before the post/pre uninstall scripts will run. This means that if you remove files in a pre uninstall but create the same files in post install, those files end up getting deleted when the old package is uninstalled.

It appears the way to handle this properly is to use pre/post trans scriptlets. Would it be possible to add options for these?

Could not generate generate-rpm in case of --target specified

@cat-in-136

v0.12.0 is not working, please check, thanks

$ cargo generate-rpm -p xxx --target x86_64-unknown-linux-gnu

# new generated file
$ ll x86_64-unknown-linux-gnu 
-rw-r--r-- 1 vkill vkill 17M Aug 10 13:28 x86_64-unknown-linux-gnu

$ ll target/x86_64-unknown-linux-gnu/generate-rpm
ls: cannot access 'target/x86_64-unknown-linux-gnu/generate-rpm': No such file or directory

Conditional dependecies

Hello,

I'm making an rpm package for an app that depends on ffmpeg,

but since ffmpeg is removed from fedora's default repos, I want to check if the user already has ffmpeg or has access to it from a different repo, and download it,

if NOT then install ffmpeg-free since it does what I need

something similar to Requires: (ffmpeg or ffmpeg-free) in the spec file

I want to do that because if I just download ffmpeg-free regardless, it will conflict with ffmpeg as I tested on my machine,

how do I do conditional dependencies in this situation?

Release Should Accept Strings

In the read-me it states that release takes a strings but when I tried this it only takes numerics.

It should use strings to allow for pre-release versions etc. I'll create a PR for this now hopefully.

Missing field: package.metadata

After command

cargo generate-rpm

I have error

Missing field: package.metadata

broken RPM generated when mode specified

Broken RPM which rpm -ivh cannot unpack files and install:

error: unpacking of archive failed on file /usr/bin/XXX;XXXXXXXX: cpio: Unknown file type

do you plan to support multiple config?

sometime a package has some bins, so it exists demand to config each bin.do you plan to support it or mind other submit pr. the confis like:

[package.metadata.generate-rpm.A]
assets = [
    { source = "target/release/a", dest = "/usr/local/bin/a", mode = "0755"},
[package.metadata.generate-rpm.B]
assets = [
    { source = "target/release/b", dest = "/usr/local/bin/b", mode = "0755"},

Would you like the `cargo-rpm` crate?

The cargo-rpm crate is unmaintained: iqlusioninc/cargo-rpm#96

If you'd like, we could give you the cargo-rpm crate name and you could potentially publish future releases of cargo-generate-rpm under that.

build/install failures due to yanked crate and also with Rust 1.53.0

Our CI job just started failing to run cargo install cargo-generate-rpm --version 0.4.0. This has been working fine until now. It fails due to a yanked aesni crate version, see https://github.com/NLnetLabs/routinator/runs/3171059667#step:9:17:

Caused by:
  failed to select a version for the requirement `aesni = "^0.7"`
  candidate versions found which didn't match: 0.99.99, 0.10.0, 0.9.0, ...

Running with --locked fails for a different reason:

cargo install cargo-generate-rpm --version 0.4.0 --locked
    Updating crates.io index
  Installing cargo-generate-rpm v0.4.0
warning: package `aes-soft v0.4.0` in Cargo.lock is yanked in registry `crates.io`, consider running without --locked
warning: package `aesni v0.7.0` in Cargo.lock is yanked in registry `crates.io`, consider running without --locked
   Compiling autocfg v1.0.1
...
   Compiling rand_core v0.5.1
error[E0308]: mismatched types
  --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/lexical-core-0.7.4/src/atof/algorithm/bhcomp.rs:62:24
   |
62 |     let bytes = bits / Limb::BITS;
   |                        ^^^^^^^^^^ expected `usize`, found `u32`

Works with Rust older than 1.53.0:

One final note: Both my local machine and our CI build both used Rust 1.53.0. When I tried cargo build locally using Rust 1.47.0 and Rust 1.52.0, both succeeded!

In a clean Docker Ubuntu 18:04 container the following worked for me:

# rustup toolchain install 1.52.0
# cargo +1.52.0 install cargo-generate-rpm --version 0.4.0 --locked

deploy to crates.io

... so that users can install it by executingcargo install cargo-generate-rpm

Release Binaries

Hello! I'm using cargo-generate-rpm in the release workflow for cloudtruth/cloudtruth-cli. I've been able to speed up the build considerably by downloading prebuilt binaries of cross and cargo-deb rather than building from source, but I am unable to do the same with cargo-generate-rpm because there are no binaries available it would be nice to be able to quickly download a release binary with cargo-binstall or cargo-quickinstall rather than compiling from source each build.

Support for --target on asset sources (cross targets)

The cargo-deb project allows asset sources to start with "target/release/" and if a cross target is being used, the location of the source is automatically corrected to "target/release//". This makes it easier to use carbo-deb with multiple cross targets. A similar mechanism in cargo-generate-rpm would make it easier as well.

example of adding assets

Hello, I'm trying to use cargo-generate-rpm but I don't quite understand the toml structure described in the README.md

I'm trying to add assets, but not sure how to, I think an example of that would be helpful, just like the example for requires

[package.metadata.generate-rpm.requires]
alternative = "*"
filesystem = ">= 3"

Future-incompatibilities warning

When install cargo-generate-rpm I'm starting to see this,

warning: the following packages contain code that will be rejected by a future version of Rust: buf_redux v0.8.4, nom v4.2.3

Using multi-line scripts

Hi,

The README.md says:

pre_install_script: optional string of pre_install_script.
pre_uninstall_script: optional string of pre_uninstall_script.
post_install_script: optional string of post_install_script.
post_uninstall_script: optional string of post_uninstall_script.

How could I instead execute entire scripts instead of single commands?

The context for this question is an RPM that needs to install systemd services and create user accounts etc.

I "hacked' around this limitation in a test by including the scripts as assets with a /tmp destination and then used the "xxx_script" hooks to execute the script from /tmp/. However, the script then also needs to take care of removing itself which is a bit ugly.

Any suggestions welcome.

Thanks,

Ximon

Getting SIGSEGV: invalid memory reference for `config::test::test_table_to_dependencies`

Hello! 🐻

I'm getting the following error during cargo test:

running 20 tests
test auto_req::builtin::test_is_executable ... ok
test build_target::test::test_build_target_path ... ok
test build_target::test::test_target_path ... ok
test auto_req::test_try_from_for_auto_req_mode ... ok
test auto_req::builtin::test_find_require_of_shebang ... ok
test auto_req::builtin::test_elf_info_new ... ok
test config::file_info::test::test_get_base_from_glob ... ok
test config::file_info::test::test_expand_glob ... ok
test config::metadata::test::test_compound_metadata_config ... ok
test config::file_info::test::test_generate_rpm_file_path ... ok
test config::metadata::toml_dotted_bare_key_parser::test_parse_dotted_bare_keys ... ok
test auto_req::script::test_find_requires ... ok
test config::metadata::test::test_metadata_config ... ok
error: test failed, to rerun pass `--bin cargo-generate-rpm`

Caused by:
  process didn't exit successfully: `/build/cargo-generate-rpm/src/cargo-generate-rpm-0.10.0/target/debug/deps/cargo_generate_rpm-d9297d9e484dcd0e` (signal: 11, SIGSEGV: invalid memory reference)

This is probably due to config::test::test_table_to_dependencies having an unsafe transmutation:

cargo-generate-rpm/src/config/mod.rs

Lines 333 to 337 in c2f1a47

	#[test]
	fn test_table_to_dependencies() {
	fn dependency_to_u8_slice(dep: &Dependency) -> &[u8] {
	unsafe { std::mem::transmute_copy(dep) }
	}

Running that test individually also fails:

$ cargo test -- "config::test::test_table_to_dependencies"

Caused by:
  process didn't exit successfully: `/build/cargo-generate-rpm/src/cargo-generate-rpm-0.10.0/target/debug/deps/cargo_generate_rpm-d9297d9e484dcd0e 'config::test::test_table_to_dependencies'` (signal: 11, SIGSEGV: invalid memory reference)

I think it would be the best if we could find a better way of comparing structs rather than using unsafe.

Building rpm for `foo-bar` package means `foo-bar/Cargo.toml` must exists?

$ cargo generate-rpm -p foo-service
No such file or directory (os error 2): foo-service/Cargo.toml

In workspace's Cargo.toml file, foo-service is in foo/service folder i.e. foo/service/Cargo.toml exits. Its a bit non-standard location but I was expecting the tool to figure it out by itself.

PS: Looks like it. Package name and its potential location is tightly linked. Package path is not being read from workspace members list.

    let config = if let Some(p) = &args.package {
        Config::new(Path::new(p), Some(Path::new("")), &extra_metadata)?
    } else {
        Config::new(Path::new(""), None, &extra_metadata)?
    };

Script parameters should accept path to files, not script intself

It's weird to have shell scripts inside Cargo.toml, especially considering that sometimes they can be quite complex.

RPM install fails with cpio bad magic

Steps to reproduce on a centos 7 machine with Rust installed already:

1. git clone https://github.com/cat-in-136/cargo-generate-rpm.git; cd cargo-generate-rpm
2. cargo install cargo-generate-rpm
3. cargo build --release; strip -s target/release/cargo-generate-rpm
4. cargo generate-rpm
5. rpm -i target/generate-rpm/cargo-generate-rpm-0.5.0-1.x86_64.rpm

Result:

error: unpacking of archive failed: cpio: Bad magic
error: cargo-generate-rpm-0:0.5.0-1.x86_64: install failed

I'm fairly certain it's the rpm-rs crate, of course, but I thought I'd report it to you first to see if you had any ideas? Thank you very much!

Reproducible builds

Right now by default generate-rpm crates non-reproducible RPMs. It can be worked around by using --payload-compress none and manually setting modification time of included artifacts right before RPM generation. Ideally, it should be handled by a simple flag.

Also I don't quite understand why enabling compression makes builds non-reproducible.

Relevant issue: rpm-rs/rpm#117

Support for `summary` silently dropped

The README still says:

summary: the package summary/description. If not present, package.description is used.

However, PR #46 removed support for this and was included in release v0.9.0, but no mention of this was made in the release notes and the README was not updated.

Worse, using summary doesn't cause an error or warning, it just doesn't have the desired effect.

I only found this because rpmlint complains about my description being too long even though I set summary to a shorter text.

Please create example directory and provide more buildable *.toml

I have a learning project to create a vaultwarden rpm that can be deployed using rpm, not docker.

• cargo-generate-rpm did the job and I got rpm like following

[me@t430 vaultwarden]$ ls target/generate-rpm/
vaultwarden-1.0.0-1.x86_64.rpm
[me@t430 vaultwarden]$ rpm -qlp target/generate-rpm/vaultwarden-1.0.0-1.x86_64.rpm
/usr/bin/vaultwarden
/usr/share/doc/vaultwarden/LICENSE
/usr/share/doc/vaultwarden/README.md
[me@t430 vaultwarden]$

• But I like to add more assets into the rpm by {pre|post}-install scripts and systemd service file.
  I have to go through the readme file without working example .toml files provided by this project.
• Please consider to open up examples directory and then newcomers can just do "cargo build --examples" to generate example rpms with different assets.

error: unpacking of archive failed on file /lib/systemd/system/xxx.service;6496c577: cpio: Digest mismatch

Hi, there

When I run sudo yum localinstall -y target/generate-rpm/*-0.1.0-1.x86_64.rpm, the Digest mismatch error happened.

But I have no problem using 0.11.0

cargo install cargo-generate-rpm --version 0.11.0 --force
cargo generate-rpm --payload-compress gzip

Inappropriate behavior package.metadata.generate-rpm.{name,version,license,summary} member presence

• If package.metadata.generate-rpm.name exists but package.name absent, package.metadata.generate-rpm.name should be used but the program actually exit by error.
• If package.metadata.generate-rpm.version exists but package.version absent, package.metadata.generate-rpm.version should be used but the program actually exit by error.
• If package.metadata.generate-rpm.license exists but package.license absent, package.metadata.generate-rpm.license should be used but the program actually exit by error.
• If package.metadata.generate-rpm.summary exists but package.description absent, package.metadata.generate-rpm.summary should be used but the program actually exit by error.

Empty requirement causes install failure

After using cargo generate-rpm I end up with an rpm that has an empty "requires":

[root@6794b4c1c5ee tmp]# rpm -q --requires /cli/target/cloudtruth-0.2.0-1.x86_64.rpm

/bin/sh

This causes install to fail:

[root@6794b4c1c5ee tmp]# rpm -i /cli/target/cloudtruth-0.2.0-1.x86_64.rpm
error: Failed dependencies:
         is needed by cloudtruth-0:0.2.0-1.x86_64

Any idea what could be causing this?

Support for `license-file`

Cargo.toml supports https://doc.rust-lang.org/cargo/reference/manifest.html#the-license-and-license-file-fields field. cargo-deb also supports the license-file field. It would be nice if we also supported license-file field.

Happy to send MR.

No 0.7.0 release tag but 0.7.0 exists on crates.io?

Hi,

The latest release tag here is 0.6.0 yet crates.io has 0.7.0.

Shouldn't there be a release tag and release notes here for 0.7.0 if that was an official release?

Thanks,

Ximon

Add support for workspace inheritance for version and other properties

Rust 1.64 added support for workspace inheritance making it possible to inherit the version and other properties from the workspace.toml.

# [PROJECT_DIR]/Cargo.toml
[workspace]
members = ["bar"]

[workspace.package]
version = "1.2.3"
authors = ["Nice Folks"]
description = "A short description of my package"
documentation = "https://example.com/bar"

# [PROJECT_DIR]/bar/Cargo.toml
[package]
name = "bar"
version.workspace = true
authors.workspace = true
description.workspace = true
documentation.workspace = true

Unfortunately cargo-generate-rpm currently does not support these.

Failed dependencies: libc.so.6(GLIBC_2.29)(64bit) is needed when install generated .rpm package

I built a .rpm package from my Rust source code within Docker Ubuntu:22.04 image then install it on the Centos:8 container and got this error:

[root@a4fe360dca8b ~]# yum install glibc
Last metadata expiration check: 16:04:45 ago on Mon 21 Aug 2023 01:09:05 PM UTC.
Package glibc-2.28-164.el8.x86_64 is already installed.

[root@a4fe360dca8b ~]# rpm -ivh strend-0.2.1-1.x86_64.rpm
error: Failed dependencies:
	libc.so.6(GLIBC_2.29)(64bit) is needed by strend-0:0.2.1-1.x86_64

Not sure what libs in my package required a higher glibc version, any way to find out?

Additional info

Build on Mac M1

--help option does not exit immediately but generates a RPM

If --help or -h option specified, the program should exit immediately. But it actually generates a RPM.

setting `CARGO_TARGET_DIR` and using auto-req results in malformed RPM

If :

• CARGO_TARGET_DIR is set to something other than target
• there are assets containing files to e.g target/release
• auto-req function is used

then the resulting RPM will contain a blank line requires, causing dnf/rpm errors.

This reproduces on cargo-generate-rpm itself by running CARGO_TARGET_DIR=foo cargo run

Support for multiple packages from single crate

Keep basename of source when it is a file and dest is directory

When specifying an asset such as

assets = [
    { source = "/usr/bin/foo", dest = "/usr/bin/", mode = "755" }
]

The result is a file named /usr/bin, even though the dest specified a path ending with a directory separator implying the path is a directory.

It would be nice if generate-rpm did the smart thing here which is to assume I want a file named foo in a directory /usr/bin/.
If dest is a directory path and source is a file path, then the basename of dest should keep the basename of source.