Per-Product Config file divergence

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/16/2014 01:16 AM, Kevin Kofler wrote:
> Stephen Gallagher wrote:
>> - From what I've seen of the planned "rich" dependencies, I don't
>> think they would provide any mechanism better than this one
>> anyway. Can you explain how you would see this working, with a
>> specific example?
> 
> foo.spec: Requires: foo-config-default or foo-config-server or
> foo-config-cloud Requires: not fedora-release-server or
> foo-config-server Requires: not fedora-release-cloud or
> foo-config-cloud
> 

Ok, so if I'm parsing this right (my boolean logic is always on the
fritz), it basically says:
If fedora-release-server is installed, then install foo-config-server
else if fedora-release-cloud is installed, then install foo-config-cloud
else install foo-config-default

(And the implication here is that fedora-release-server Conflicts with
fedora-release-cloud).


That's probably a reasonable approach, assuming those rich
dependencies work as advertised and are available in Fedora 21. (I've
heard that they're present in RPM itself, but so far the FPC has not
approved any such usage. This example is probably worth raising with
them.)

Thank you for the explanation. The above approach is also fairly
future-proof, as if we add a new Product to the line-up, that Product
would just pull in foo-config-default until and unless the maintainer
decided to add a new, Product-specific config sub-package.


As noted above, this makes a couple implications for future usage,
however:

1) If we select this route, we make it impossible to have co-tenancy
of two Products (e.g. Server and Workstation). This seems to be a
statement that the various groups have been circling in on, and I'm
coming to see the value in making this assertion.

2) Unless I misunderstand how the dependency-resolution works, it
becomes impossible to change from one Product to another (e.g. Cloud's
adopt-a-server switch to Server).[1]




[1] I could be wrong here; it depends on how RPM and YUM handles 'yum
remove fedora-release-cloud; yum install fedora-release-server'. Lets
assume that foo has foo-config-cloud installed. I see three possible
outcomes to 'yum remove fedora-release-cloud':
 1)  foo-config-cloud is removed and foo-config-default is installed
 2)  foo-config-cloud remains on the system, irrespective of the
     presence of fedora-release-cloud
 3)  The transaction aborts because of unsatisfied dependencies.

Similar questions are therefore inherent with 'yum install
fedora-release-server' after that: do packages get the server default
configs or do they remain with the cloud or default configs?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMm6gwACgkQeiVVYja6o6PeYACfeYhu2SIY8/9KRP7sXDrRnr9U
6d8AoImUXiaOZYyHOXQjHnMpjXjpjF79
=9zKP
-----END PGP SIGNATURE-----