Configuration files missing %noreplace?

[bjornwiberguuse]

Hello Yannick!

It appears that the Rock configuration files are not marked as %noreplace, resulting in configuration overwrite on updates:

[root@server ~]# rpm -q --qf '[%{filenames}: %{fileflags}\n]' rock
/etc/default/rock: 0
/etc/rock: 0
/etc/rock/Rprofile.R: 1
/etc/rock/Rserv.conf: 1
/etc/rock/application.yml: 1
/etc/rock/logback.xml: 1
/etc/rock/system.info.R: 1
/usr/lib/systemd/system/rock.service: 1
/usr/share/rock-1.0.10/bin: 0
/usr/share/rock-1.0.10/bin/start.sh: 0
/usr/share/rock-1.0.10/bin/update.sh: 0
/usr/share/rock-1.0.10/lib: 0
/usr/share/rock-1.0.10/lib/rock-1.0.10.jar: 0
/var/lib/rock: 0
/var/log/rock: 0
[root@its-srv151 ~]#

Would it be possible to have the configuration files in /etc/rock marked as %config + %noreplace so that any custom changes persist on updates?

Also, /etc/default/rock is not tagged as a configuration file at all, so any Java argument changes (for example) are lost on upgrades. Perhaps that one should be marked as %config + %noreplace too?

Many thanks in advance!

[ymarcon]

That's correct for the /etc/default/rock: it is not flagged as a config file at all.

For the /etc/rock/* it should normally be the case: These files get special treatment during package installation to ensure that local changes to the configuration are not lost. Is the noreplace modifier really needed?

[bjornwiberguuse]

Hello Yannick!

Thank you for your reply!

Yes, sadly, it is needed, because otherwise the customized configuration files will simply be saved as ".rpmsave". I believe the "special treatement" is simply that they save the old (customized) versions, i.e. do not completely remove them from disk.

With %config(noreplace) the stock (package) versions will be saved as ".rpmnew" and the customized versions will be left as-is, which would be desired for most configuration files.

[ymarcon]

Please try with 1.0.11-beta. Now I got this:

[vagrant@fedora32 ~]$ rpm -q --qf '[%{filenames}: %{fileflags}\n]' rock
/etc/default/rock: 17
/etc/rock: 16
/etc/rock/Rprofile.R: 17
/etc/rock/Rserv.conf: 17
/etc/rock/application.yml: 17
/etc/rock/logback.xml: 17
/etc/rock/system.info.R: 17
/usr/lib/systemd/system/rock.service: 17
/usr/share/rock-1.0.11-beta/bin: 0
/usr/share/rock-1.0.11-beta/bin/start.sh: 0
/usr/share/rock-1.0.11-beta/bin/update.sh: 0
/usr/share/rock-1.0.11-beta/lib: 0
/usr/share/rock-1.0.11-beta/lib/rock-1.0.11-beta.jar: 0
/var/lib/rock: 0
/var/log/rock: 0

[bjornwiberguuse]

Hello Yannick, and thank you for your reply!

Looks good, except that /usr/lib/systemd/system/rock.service should actually not be a configuration file at all, as any overrides should be performed in /etc/systemd/system (as per https://www.freedesktop.org/software/systemd/man/systemd.unit.html#id-1.14.3) -- and that the directory /etc/rock should not itself be flagged as %config, only the specific configuration files (as per http://ftp.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html#S3-RPM-INSIDE-FLIST-CONFIG-DIRECTIVE and https://docs.fedoraproject.org/ro/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch09s05s03.html).

[ymarcon]

ok for the rock.service not being a config!

That's what I get in the RPM specs:

%config(noreplace) %attr(750,rock,adm) "/etc/rock"
%config(noreplace) %attr(644,-,-)  "/etc/default/rock"

and after install:

[vagrant@fedora32 ~]$ rpm -q --qf '[%{filenames}: %{fileflags}\n]' rock
/etc/default/rock: 17
/etc/rock: 16
/etc/rock/Rprofile.R: 17
/etc/rock/Rserv.conf: 17
/etc/rock/application.yml: 17
/etc/rock/logback.xml: 17
/etc/rock/system.info.R: 17
/usr/lib/systemd/system/rock.service: 0
/usr/share/rock-1.0-SNAPSHOT/bin: 0
/usr/share/rock-1.0-SNAPSHOT/bin/start.sh: 0
/usr/share/rock-1.0-SNAPSHOT/bin/update.sh: 0
/usr/share/rock-1.0-SNAPSHOT/lib: 0
/usr/share/rock-1.0-SNAPSHOT/lib/rock-1.0-SNAPSHOT.jar: 0
/var/lib/rock: 0
/var/log/rock: 0

Are you sure there is a problem with having the /etc/rock directory being flagged? I am not sure that the spec's line is in conflict with what stated in the doc.

[bjornwiberguuse]

Hello Yannick!

I'm unsure whether tagging /etc/rock as %config or %config(noreplace) would have any side-effects (e.g. acting as a "default" for files placed there, similar to %docdir).

Is it correct that the Maven RPM plugin only "operates" on directories, and that files cannot be enumerated one by one?
If so, I guess we'll simply have to live with /etc/rock being tagged with %config(noreplace). :-)

[ymarcon]

Same changes applied to opal, mica2 and agate, thanks (again)!

[bjornwiberguuse]

Hello again Yannick!

When will these new RPMs (opal-server, mica2 and agate) with the %config(noreplace) be published at https://obiba.jfrog.io/ui/native/rpm-local? It appears that there are only "older" versions there.

Thanks in advance!

[ymarcon]

Hi, I have just released rock 1.0.11.

[bjornwiberguuse]

Hello, Yannick, and thank you!

Will this be applied also to opal-server, mica2 and agate in the near future? (Many thanks in advance!)

[ymarcon]

Yes, this week or next week.

[bjornwiberguuse]

Thank you very much, Yannick! It is much appreciated!