Question: I'm packaging some of my own software, as part of the installation I need 
to drop some config files in a directory that's used by a 3. party.

To avoid overwriting configuration that have been locally changed, that file is marked as a config file like so in the RPM .spec file:

```
%config(norelace) /opt/lmd/conf/srv1.conf

```

The issue is that upgrading an rpm will now produce the file 

```
 /opt/lmd/conf/srv1.conf.rpmnew

```

if /opt/lmd/conf/srv1.conf have been altered locally. And the 3.d party software reads everything in /opt/lmd/conf/\* . 

Can I somehow mark a config file in the RPM .spec file to not produce such an `.rpmnew` file ?

Answer: 
Not that I'm aware of. This (and the human-made equivalents `.bak`, `.off`, `.tmp` etc.) is why most tools glob `*.conf` or similar when they read configuration files.

If you can't modify the third-party tool to fix that problem then you really can't do much about this short of not installing to that directory directly and making the user do the copying.

(You could package the old file too or sums of the old config file and check those against the current file in `%post`, etc. but that's ugly, manual and prone to possible failures.)

You *might* be able to manually remove/move the `.rpmnew` files in your `%post` (or `%posttrans`) scriptlet but I don't know if that's actually possible (timing-wise).
Those backups are done for good reasons and only if those files were altered. Here is described when is created .rpmsave and when .rpmnew: <http://www-uxsup.csx.cam.ac.uk/~jw35/docs/rpm_config.html>

There exist tool `rpmconf`, which can help find, merge and delete those files. But since it query rpm database (and because it is interactive) you should not call it from rpm scriptlet. 

If the 3rd party SW reads everything in /opt/lmd/conf/\* then I will call that bug, because best practice is to read just /opt/lmd/conf/*.conf This way e.g. httpd - reading /etc/httpd/conf.d/*.conf. So contact your supplier and report it as bug.