During a world upgrade, xosview was upgraded to 1.17. In doing so, it replaced the system-wide app-defaults file at /usr/share/X11/app-defaults/XOsview with its own version, without creating a backup. Unfortunately, this was a file that took me a whole day to configure with the right colors and configurations. I consider this to be a bug, and a big one at such. The installation procedure (at least: the ebuild) should issue a warning and save the old app-defaults file somewhere, giving the user the chance to save days of work. It should also say something along the lines of "Original /usr/share/X11/app-defaults/XOsview saved as /usr/share/X11/app-defaults/XOsview.bak. Please consider creating /etc/X11/app-defaults/XOsview if you need a system-wide app-defaults file, because /usr/share/X11/app-defaults/XOsview will always be overwritten." You ruined my day.
Sorry to say so but IMHO you are wrong in several levels. First, the location /usr/share/X11/app-defaults is meant for packages to install their default configuration files: x11-apps/xmessage x11-misc/xlockmore x11-misc/xosview x11-terms/xterm (and perhaps a couple more of them). Second, you still can add the /usr/share/X11/app-defaults directory to your CONFIG_PROTECT variable in /etc/portage/make.conf file, which does exactly what you describe but slightly different (see "man 1 etc-update" and "man 5 make.conf"). Third, user defined configurations for xosview are supposed to land in ${HOME}/.Xdefaults file where no package manager would ever mess with its content.
Well, yes and no. First of all, thank you very much for such a swift answer. I would never expect such a quick reaction. To the points you make, I have this to say: 1) Yes, of course /usr/share/X11/app-defaults/ is the system-wide configuration place. BUT NOT ONLY FOR THE PROGRAM! For the administrator too! The administrator is not supposed to change all his users' .Xdefaults files to create a "standard look" for a program! He is supposed to change ONE location - and where is this? That's /usr/share/X11/app-defaults/. 1a) Even if we suppose that the administrator should NEVER EVER change ANYTHING in /usr/share/X11/app-defaults/, the installation procedure should be graceful about it, i.e. INFORM and BACKUP, no matter what. It doesn't matter that (or whether at all) you are right and I am wrong. What matters is whether you ruin my day or not. RPM would NEVER, EVER do this! It would ALWAYS back up a file whose MD5 has changed since installation and inform the user that "file xyz was saved as xyz.rpmsave". And portage cannot? 2) Which brings us to your second point. Oh yes, now I know - the hard way....Portage CAN do it, but I have to smell my fingers and GUESS which of all possible directories might be overwritten without notice - THEN yes, it can do it. But no, that's "theoretically correct", but practically a recipe for disaster. I was SURE portage would NEVER touch something I changed without making a backup for me. Actually, now that I think of it, it should always do a backup and only NOT do it, if I tell it so - not the other way round! "We backed up xyz as xyz.bak for you, because it changed since last installation. If you don't want this kind of behaviour, please add directory X to the DONT_BACK_ME_UP list". 3) See 1). I will NOT go into each and every ~/.Xdefaults file of a user. Not my business what *they* define. But when *I* want to define a system-wide look for xosview, where am I supposed to do it? In ONE place? I just tried /etc/X11/app-defaults/XOsview but it is NOT taken into account (even if I know, from an strace of some previous version at least), that xosview does look to see if it is there...
