From Fedora Project Wiki
No edit summary |
No edit summary |
||
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 :-)
- 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.
- 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
- 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)
- 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