rpm: packages with undefined values are written as empty strings

[dekimsey]

What happened?

nfpm appears to conflate empty string and undefined fields when writing out the rpm headers. Unspecified configuration parameters get set to the empty string "". Whereas an equivalent configuration is created manually with rpmbuild these parameters are left out of the headers (some may have defaults like Group: Unspecified).

I'd like nfpm to skip writing these headers instead of setting them to the empty string. I don't know if the intent of the project is to mimic rpmbuild's behavior or not. But at least for empty fields, yes please :)

Thank you!

Background:
We identified this issue when (after migrating to nfpm) customers reported that our packaging now had fields that were unspecified. We identified that our packages did indeed have empty fields set that show up under rpm -qpi .../my.rpm.

How can we reproduce this?

For context, a minimum spec file indicating `rpmbuild`'s required fields

$ echo "# empty spec" > empty.spec
$ rpmbuild empty.spec
error: Name field must be present in package: (main package)
error: Version field must be present in package: (main package)
error: Release field must be present in package: (main package)
error: Summary field must be present in package: (main package)
error: License field must be present in package: (main package)

A minimally specified RPM spec file, build, and resulting metadata:

$ cat <<EOF >minimum.spec
Name: hello-world
Version: 1.0
Release: 1%{?dist}
Summary: Minimum viable RPM
License: Not applicable
# rpm will error building the package after initially reading the spec, so add a description
%description
Nothing to say
# a files directive is required to get rpmbuild to produce a binary rpm
%files
EOF
$ rpmbuild -ba ./minimium.spec
...
$ rpm -qpi /root/rpmbuild/RPMS/aarch64/hello-world-1.0-1.el8.aarch64.rpm
Name        : hello-world
Version     : 1.0
Release     : 1.el8
Architecture: aarch64
Install Date: (not installed)
Group       : Unspecified
Size        : 0
License     : Not applicable
Signature   : (none)
Source RPM  : hello-world-1.0-1.el8.src.rpm
Build Date  : Thu Feb  9 17:43:07 2023
Build Host  : bc131da7f799
Relocations : (not relocatable)
Summary     : Minimum viable RPM
Description :
Nothing to say

An equivalently minimum yaml config showing nfpm's undefined parameters behavior:

$ cat <<EOF >spec-equiv.yaml
version: 1.0
release: 1
license: Not applicable
description: Nothing to say
rpm:
  group: Unspecified
  summary:  Minimum viable RPM
$ nfpm package -p rpm --config ./spec-equiv.yaml
using rpm packager...
created package: hello-world-1.0.0-1.x86_64.rpm
$ rpm -qpi ./hello-world-1.0.0-1.x86_64.rpm
Name        : hello-world
Epoch       : 0
Version     : 1.0.0
Release     : 1
Architecture: x86_64
Install Date: (not installed)
Group       : Unspecified
Size        : 0
License     : Not applicable
Signature   : (none)
Source RPM  : hello-world-1.0.0-1.src.rpm
Build Date  : Thu Feb  9 17:46:23 2023
Build Host  : myhostname
Relocations : (not relocatable)
Packager    :
Vendor      :
URL         :
Summary     : Minimum viable RPM
Description :
Nothing to say

These tests were conducted on an CentOS 8 box. I don't know if this might be differences between how RPM displays/records the data in the header. But since we are writing the headers in pure-Go, I'm assuming it's just the fact that we are recording empty strings instead of skipping.

nfpm version

nfpm version nfpm version v2.25.0

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

I'm not an RPM expert (so I don't think this is a wise approach), but I did add a one-liner skip logic to index.Add to test the behavior of excluding empty fields and see what the package looked like (see below). Though I think the correct behavior would be to make many of these optional fields *string so nfpm can disambiguate.

Quick and dirty hacked-in support for empty field handling

$ git diff
diff --git a/internal/rpmpack/header.go b/internal/rpmpack/header.go
index b223672..9659438 100644
--- a/internal/rpmpack/header.go
+++ b/internal/rpmpack/header.go
@@ -109,7 +109,10 @@ func newIndex(h int) *index {
 }

 func (i *index) Add(tag int, e IndexEntry) {
-       i.entries[tag] = e
+       // FIXME: Hack to skip empty fields
+       if len(e.data) > 1 {
+               i.entries[tag] = e
+       }
 }
$ go build
$ ./nfpm package -p rpm --config ./rpm-equivalent.yaml
$ rpm -qpi /src/hello-world-1.0.0-2.x86_64.rpm
Name        : hello-world
Epoch       : 0
Version     : 1.0.0
Release     : 2
Architecture: x86_64
Install Date: (not installed)
Group       : Unspecified
Size        : 0
License     : Not applicable
Signature   : (none)
Source RPM  : hello-world-1.0.0-2.src.rpm
Build Date  : Thu Feb  9 17:53:56 2023
Build Host  : myhostname
Relocations : (not relocatable)
Summary     : Minimum viable RPM
Description :
Nothing to say

Which looks far more like what I would expect to have given my inputs.

[caarlos0]

depends on google/rpmpack#88

[pkitszel]

depends on google/rpmpack#88

Looks like this is not going to be merged, as it is a breaking change for the rpmpack.

What about reserving one value NO_EPOCH (likely 0xffffffff) in rpmpack, that would mean "do not emit epoch entry", and make it a default in nfpm (which will be overriden by explicit request in .yml, but otherwise left as NO_EPOCH).

[caarlos0]

I think that could be a good solution... want to propose that in there?

[yakhatape]

I'm facing the same issue into my spacewalk repository for recent elastic package which use nfpm ..
When spacewalk try to index package, vendor flag is empty string instead to be NONE (not present) and create an error into the database which return a violation constraint : "a NULL value violates the NOT NULL constraint of the column"

did you have any news about this issue ?

[caarlos0]

see #809