Make configuration files being ignored during verify

[OliverMatz]

We are facing essentially the same problem as described in https://stackoverflow.com/questions/38993603/rpm-verify-ignore-config-files: The pom.xml contains an entry like this:

<entry>
  <name>/opt/foo/configure-foo.properties</name>
  <file>${project.build.directory}/configure-foo.properties</file>
  <mode>0666</mode>
  <configuration>true</configuration>
</entry>

The rpm-maven-plugin creates an rpm file that contains a configuration file configure-foo.properties. After the user has edited that file and uses RPM's verification as described in https://www.linux.co.cr/distributions/review/2002/red-hat-8.0/maximum-rpm-1.0/ch-rpm-verify.html that tool treats this as a mismatch.

I would expect the file configure-foo.properties to be ignored, which should be possible with the spec file directive %verify(owner group) /opt/foo/configure-foo.properties. Basically, I see three ways to achieve this in our build process:

1. No change to the pom.xml is needed and the rpm-builder plugin adds a suitable %verify directive by default, or
2. I add a nested element such as <verifyexclude>true</verifyexclude> to the respective entry in the pom.xml, or
3. I write a separate nested such as <verifyparams>owner group</verifyparams> to the respective entry in the pom.xml

I slightly favour the first option. This issues is related to #7

[ctron]

It might indeed be interesting to be able to configure the verify parameters. However, I am not sure "how". One thing to be figured out :grinning:

It is not simple as adding %verify, because that would be part of a "spec file", and this plugin doesn't use spec files. As they are bound to be used by the rpm tool, and that would make it platform dependent.

I think what could be a proper solution, would be to add a <verifies> element, plus some kind of "enum", which defines what to verify. The default (no element) being the current behavior.

[OliverMatz]

I have programmed an experimental workaround that solves the problem in my case, but might be an acceptable solution for others, too. I assume that for all practical purposes, if a file inside the rpm is classififed "configuration" with "noreplace", then it is reasonable to ignore it during verification without any further ado. This can be accomplished by the following modification in project org.eclipse.packagedrone.utils.rpm, class org.eclipse.packagedrone.utils.rpm.build.RpmBuilder.BuilderContextImpl, method customizeFile(FileEntry, FileInformation):

final Set<FileFlags> fileFlags = information.getFileFlags ();
if (fileFlags.containsAll(Arrays.asList(FileFlags.CONFIGURATION, FileFlags.NOREPLACE))) {
     entry.setVerifyFlags(0); // set empty bitmask 
}

Here, the statement entry.setVerifyFlags(0); sets a bitmap that suppresses verification completely. A more refined solution would be to set a bitmask that corresponds to %verify(owner group) in the spec file.

I realize that this proposed change is a bit drastic and changes the behaviour compared to earlier versions of org.eclipse.packagedrone.utils.rpm.

A more versatile and canonical solution would be the one ctron has suggested. That would require some (straightforward) changes both in the project org.eclipse.packagedrone.utils.rpm and in the project de.dentrassi.maven:rpm.

Now my question is: How to proceed?

Of course, I would prefer a "sustainable" solution, where all code changes go into the official code base of the respective open source projects.

[OliverMatz]

The problem should be solved with my two pull requests https://github.com/eclipse/packager/pull/6 https://github.com/ctron/rpm-builder/pull/43 The second one fails with a maven dependency failure just because it depends on the first one.

What now?

[ctron]

Version 1.3.0 is released which should contain this. Maybe you can test and close the issue.

And thank you for the contribution!

[OliverMatz]

Fixed in Version 1.3.0. The xml-element entry may now contain an optional nested xml-element verify.

• If that element verify is not present, the behaviour is unchanged: all flags will be set and everything will be verified
• If that element verify is present, it specifies a (possibly empty) list of those flags that shall be verified, then only those will be set in the bitmap and only the corresponding aspects will be verified. The following example specifies the all 9 flags that are documented in http://ftp.rpm.org/max-rpm/s1-rpm-verify-output.html:

  <verify>
  <fileDigest>true</fileDigest>
  <size>true</size>
  <linkto>true</linkto>
  <user>true</user>
  <group>true</group>
  <mtime>true</mtime>
  <mode>true</mode>
  <rdev>true</rdev>
  <caps>true</caps>
  </verify>

  Note the difference between a missing and an empty verify-element: In the former case, everthing will be verified, and in the latter, nothing will be verified.

The appropriate configuration for my original use case is:

    <entry>
        <name>/opt/foo/configure-foo.properties</name>
        <file>${project.build.directory}/configure-foo.properties</file>
        <mode>0666</mode>
        <configuration>true</configuration>
        <noreplace>true</noreplace>
        <verify>
            <user>true</user>
            <group>true</group>
        </verify>
    </entry>