A couple of people have made similar feature requests of this nature in the
past.  Since we're in a time of change right now, I'm looking at the request
from a viewpoint of "what is the basic underlying feature being requested",
rather than looking at a specific implementation.

In other words, to provide this type of functionality, I believe we should
do it in a generic and global manner.  Currently, the supplied app specific
resource files are intentionally not flagged as configuration files, as
they are not intended to be used for customization directly.  They are
intended to be static files supplied by the OS which define the OS default
behaviour.

One thing we must retain, is the ability to change app specific resource
settings in a package update, and ensure that /all/ systems get the changes
when they apply the update - even if they have made customizations to the
default resources for the particular application.

In current rpm spec file parlance, this does not really give us very good
options.  We currently treat these files as statically supplied "data"
files, and not as administrator editable "config" files, in order to meet
the goal outlined in the previous paragraph.

If we were to move them into /etc and flag them as %config, this would
mark them as config files, and would backup the admin modified config
on upgrades, but replace it with our updated copy.  That would also
serve our purpose of ensuring that any changes we make would be
immediately visible on upgrade.  The downside to this approach, is that
it still disables the admin customizations, which can be fairly annoying
to an administrator who then has to go make changes by hand again later.

Also, if they just copy their original back over our updated file, they
will lose the changes we have made, which sometimes are security related,
such as has happened for Xterm many times in the past.  In general, when
we flag config files as %config, we eventually get a number of bug reports
asking to use "%config(noreplace)" instead.  If we use that however, then
we once again lose the property of being able to ensure all users have
got the latest vendor supplied configuration updates.

From a package maintenance and support perspective, the property of
guaranteeing /all/ users are using our updated vendor supplied
config data when they update is of the highest level of importance.
Aside from possible security implications, sometimes applications
change over time, and old configuration settings are no longer valid,
and can cause additional (and unnecessary) bug reports.

On the other hand, having the ability to customize applications at the
sysadmin level and not have them be overwritten or renamed out of the
way is also a nice desireable property.  The current recommended way
of making such customizations in the OS, is to make these changes in
systemwide /etc/X11/Xresources or similar files, however that has
some disadvantages to the administrator as well.

Taking all of this to consideration, I've been thinking about this problem
tonight, and how we might best be able to solve it in a way that gives us
what we need from the distribution maintenance and support side of things,
while also giving a useful enhancement to system admins and users out
there, without having to compromise.  I just came up with an idea which
I think will serve the purpose on both sides of the fence.

Short version:  /etc/X11/Xresources.d


Long version:  By adding a new /etc/X11/Xresources.d directory to the
system, and updating the X startup scripts to load the resource files
found within, this would keep the system supplied resource files in
tact, and would make it very easy for sysadmins to drop in custom
per-application resource files.  These custom resource files would not
be supplied by OS vendor packaging, and would thus survive OS and
package upgrades.  However, sysadmins could certainly package their
own set of resource files into custom rpm packages which get installed
in this location.

I've discussed this with the Debian/Ubuntu X maintainer and a few other
distribution maintainers, and it appears that this is the solution they
implement as well.  As such, I am going to consider implementing the
support for /etc/X11/Xresources.d in the future, in order to both provide
the functionality for custom global configuration that doesn't get blown
away, while retaining the RHAT vendor supplied files intact.

Community feedback is appreciated.

I disagree, but I understand where you are coming from.

Adding /etc/X11/Xresources.d would continue a trend to devolution.

Is it true that /usr/X11R6/lib/X11/app-defaults contains configuration data?
Is it true that it is located in a non-standard location?
Is it true that adding multiple places where configuration can be done tends to
add confusion and create a mess?

I suggest that install should move app-defaults to /etc/X11 and create a
symbolic link from original location.  And the rpm spec should declare them as
%config.

Keep it plain and simple.

The "defaults" in app-defaults is pretty much self-explanatory imo.

What Mike is suggesting is a slightly easier mechanism for doing what most
people do using ~/.Xresources currently, i.e. override or extend the default
settings, such as changing the fonts used in xterm, or changing default colours.

Putting a system-wide method of supplying such overrides in place means that an
administrator can override the default settings without changing the distributed
app-defaults files (which are really part of the application).

Given that most people use ~/.Xresources to modify and X resources, and that
modern applications have largely moved away from X resources, I don't see us
ever implementing this, so closing WONTFIX.