From Fedora Project Wiki
Line 8: Line 8:
 
# '''install time''' -- we want the product you're installing to determine which configuration you get.
 
# '''install time''' -- we want the product you're installing to determine which configuration you get.
 
# '''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.
 
# '''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.
# 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.
+
# '''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.
 +
## Tool should not switch out user-modified configs unless run with --force
  
 
=== Discussing ===
 
=== Discussing ===

Revision as of 18:43, 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 conversion/union: Installed Cloud or Server but want a graphical environment. Preference is to make that be Workstation. (We want it to be as close to Workstation as possible, to benefit from existing testing)
    1. recommendation implementation: the defaults should not change for anything that was part of the installed Product, but new packages should get the Workstation default

Possible Implementations

  • Conflicts
  • Alternatives