From Fedora Project Wiki
(Update the Product union case)
Line 33: Line 33:
  
 
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.
 
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.

Revision as of 19:56, 7 March 2014

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

Use cases

Agreed upon

(at least sgallagh and abadger1999 :-)

  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

Discussing

  1. Product union: Installed Cloud or Server but want a graphical environment.
    1. 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).
  1. 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.

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.