User:Toshio/Product Divergence (config)

We want to have products be able to specify divergent and conflicting behaviour.

Use cases

1. install time -- we want the product you're installing to determine which configuration you get.
2. installing a package on an existing system -- if it has separate config, we'd like the package manager to choose the configuration for the product you're using.
3. Want to have a single tool that can switch default configs per-package. Which things you can switch may depend on what combinations we support and how the user has selected which Products are "active" on their system.
   1. Tool should not switch out user-modified configs unless run with --force
4. Product installed as Cloud or Server but want a graphical environment. Currently, yum groupinstall @GNOME is suggested but it doesn't lead to the same thing as you get when you install the Workstation Product (configs would be different)
   1. Note: this use case sees more debate than the previous ones.
   2. The system would know that it was installed as a certain product. When you install a package, you can decide to install that package as if it were for a different product (and thus get the configs for that other product). To get a graphical environment you could do something like yum groupinstall --product=workstation <workstation-comps> which will get you the default package-config for workstation.
   3. This allows you to more closely mimic what you'd get with a workstation install.
   4. not sure how useful this will prove to be, though: since the underlying reason for divergency isn't addressed we might just be offering the end user this: "yum install package... Why isn't Foo working? yum reinstall --product=workstation package.... Now why isn't Bar working?"
   5. Leaves many corner cases (For instance, package from the workstation comps group installed into Server without using --product=workstation. Then yum groupinstall --product=workstation <workstation-comps>. This will put the system in a state where some of the packages workstation needs are installed with server config and other packages are installed with workstation config)
   6. You put a desktop on server using technologies that may be developed by the Workstation WG. Putting the Workstation product on Server product doesn't seem to make sense.
5. Product conversion: Installed Cloud or Server but want a graphical environment. Convert existing config to workstation and install additional packages on top to get a Graphical environment.
   1. Did not discuss but seems easier than the install-package-foo-as-if-for-a-different-product use case.

Possible Implementations

• Conflicts
• Alternatives

Identifying the Product

• /etc/os-release?
• /etc/fedora-release?
• /etc/fedora-release.d?

Needs to allow us to specify different Products.

If we have layered/unioned Products it would need to allow us to decide which Product gets precedent from this information.

Some choices would make more sense if we're going to remain committed to some commonality between Fedora Products. If there's a base system that's common, for instance, then /etc/fedora-release might identify that and we would want to know products in addition to that. At the other end of the spectrum, if the Products were each releasing on their own timeframe and had many divergent packages, then having release information associated with "Fedora" might not make sense.

• There's a desire to identify which platform guarantees the system implements. ie: if I install all the packages required for server and all the packages required for workstation, then the system should identify as implementing both of those.