Bug 2034804

Document URL: 
https://access.redhat.com/documentation/en-us/red_hat_satellite/6.10/html-single/content_management_guide/index#Managing_Content_Views-Defining_Content_Filters

https://access.redhat.com/documentation/en-us/red_hat_satellite/6.10/html-single/content_management_guide/index#Managing_Content_Views-Resolving_Package_Dependencies


Section Number and Name: 
7.7. Content Filter Overview
and
7.8. Resolving Package Dependencies


Describe the issue: 
Currently, the text implies all combinations of include/exclude filters and/or depSolve are supported and all of them will produce "expected" results. Which is not correct, as:
1) combining include and exclude filters itself (regardless of depSolving) can have some undesired results in some use cases (I dont recall details, but I do recall some customer issues around); we should review if the "Include and Exclude Filter Combinations" paragraph is really correct.
2) enabling dependency solving has several gotchas:
  a) it does not work well with exclude filters (exclude feature and "include more for dependency" feature are opposite, and the way how we concurrently apply them lead to VERY unpredictable outcome, in general)
  b) even with include filters or without any filter, dep.solving attempts to resolve missing dependency by adding *newest* package that fulfills the dependency requirement - that is a crucial "yum, update me as high as possible, please" feature of RPM-land. This sometimes leads to outcome unexpected to the user ("why such newest package was added, if that dependency was already resolved by some older version of the package, already included in the CV?")
  c) even with just include filters or without any filter, dependency solving on CV still can produce a CV content that can hit dependency conflicts during yum/dnf update (esp. due to b) factor) - we should stress that "dnf update" is not a proof of CV depsolving functionality (but to be fair, we should postulate what *is* such a proof depsolving is working well)

TL;DR: we need to:
- have a table of supported/unsupported/maybe-working-but-the-devil-is-in-details combinations of include+exclude+depsolving combinations
- clarify expected outcome of the filters or depsolving, per above points

While bz2031096 (or some related bug) will be meant to disallow unsupported combinations in WebUI, this BZ stands for explanation of that stuff in our doc.


Suggestions for improvement: 
See above

Additional information: 
Ideally, we should update doc for all (supported) versions. Anyway doing so for 6.10 or newer is imho sufficient (there can be differences between 6.8-6.9 and 6.10 due to pulp-3, which would add too much doc work for a low price).