On May 29, 2015, at 3:25 PM, Elan Ruusamäe wrote: > On 29.05.2015 17:43, Jeffrey Johnson wrote: >> I won't make the change in RPM upstream because I believe it's >> more important to have consistent %config handling than it is to >> preserve unpackaged configuration files on upgrade when the >> new (but not the old) package has file content (which almost never happens). >> >> I can be convinced otherwise if there is a demonstrable consensus that a >> different >> behavior is needed and necessary. > the scenario is quite simple: > > some software loads config from conf.d dir (using *.conf glob), at some point > sysadmins put their configs there. > now rpm starts to put their files there too, it happens to be the same > filename, > now if the file already exists, it will ovewrite sysadmin changes. > > if it created .rpmnew, then the previous file (created by sysadmin) would be > used, and new config (from rpm), would be stored as .rpmnew > > overall config stays running, nothing is overwritten. >
The alternative scenario is equally plausible: Sysadmin is trying to install software manually, lacks expertise in configuring. Eventually\ the sysadmin attempts install from rpm packages, mis-configuration is overwritten, and everything Just Work. Which isn't true if the newly installed configuration is renamed with a .rpmnew suffix. Enough already: you know well how RPM behaves with %confoig, and you are able to patch in whatever behevaior you choose: I told you how to patch in the behavior you desire. (aside) You do realize that RPM5 embeds libgit2 sufficiently well to perform a commit that git(1) understands? Discusssing Newer! Better! Bestest! %config handling, with (.rpmnew/.rpmorig/.rpmsave) handling is so so so last century ... *shrug* 73 de Jeff > -- > glen > > _______________________________________________ > pld-devel-en mailing list > pld-devel-en@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en _______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
