Per-Product Config file divergence

[Bill Nottingham]

Toshio Kuratomi (a.badger at gmail.com) said: 
> At last week's FESCo meeting, the fact that Products desired to have
> divergent configuration was briefly touched on.  On Thursday, a few FPC
> members had a brainstorming session about it and on Friday, sgallagh and
> that brainstorming continued with sgallagh, adamw, tflink, notting, and
> myself.  We came up with a tentative idea here:

Well, I read a couple hours of backscroll and made two comments; I don't
really think that qualifies me as a co-author. That being said...

> https://fedoraproject.org/wiki/User:Toshio/Product_Divergence_(config)
> 
> The idea is to allow config file divergence via the alternatives system as
> that already provides us with a commandline tool and some structure to build
> on.  We'd still have to write a few pieces to complete the picture but it
> seemed to be a better starting point than using rpm Conflicts between
> config-packages.

... I'm not really convinced that alternatives is the way to go here. For
one, it's implemented as symlink farms; depending on how tools modify
configuration, that can cause problematic/unpredictable drift.

Stepping back, if you allow this, in general, you get the following
potential bifurcation for any one product:

a) the default config when in Server
b) the default config when in Cloud
c) the default config when in Workstation
d) the default config when in spin XYZ
...
z) the default config when in none of the above

etc.

I'm struggling to think of a viable case where we want users to be able to
pick any of the above for a package running on any other of the above. It
would seem simplest to me that for any package, you either get the config
for your particular product that you have installed, or you get z) if it
doesn't have one for your product. Among other things, this simplifies the
test matrix.

Bill