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 Implementation

• Note: Some services will have their own means of shipping and choosing differing default config. Those would not need to use this system -- this system is mostly about how we should handle services that don't have that flexibility builtin.

Use the Alternatives System

One package can install several different config files and switch between them using the alternatives system. Alternatives should take care of the minimum needed to install both sets of configs on the system and provide a commandline tool to switch between the configs. We'd need to come up with some packaging guidelines/scriptlets or macros to select the default configs based on what Product we're installing onto. We would also need a yum/dnf plugin to implement the ability to override the product we're installing into via the commandline.

Use Conflicts

We originally thought we might want to use Conflicts to implement this but after discussion it seemed that alternatives was a better fit. alternatives already provides us with a few tools and structure that we'd have to reinvent if we used Conflicts instead.

Other thoughts

Identifying the Product

A side issue to this is how to identify what Product we're running. Some choices:

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

Needs to allow us to specify different Products because Fedora Workstation won't be the same as Fedora Server.

The identifier would need to allow us to determine which Product we want the configs for (by default).

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 the Fedora Version and product information would be 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 so we could just express the Product information in fedora-release.

• 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 could identify as implementing both of those. The problem here is that not every guarantee is going to be about packages and some guarantees may conflict between platforms. For instance, a configuration setting such as which SELinux policy the system runs could be a different guarantee between Products. Since there's only one policy for the system, you wouldn't be able to have a system that claimed to implement both of those Products.

Approval of divergency?

sgallagh was of the opinion that FESCo should approve all requests for divergent configs and that the bar should be set pretty high for what would be allowed. Some examples would help to clarify this.