Bug 881866

Description of problem:

For 3.x we provide a context sensitive help mechanism. It is driven by two CSV files which link GUI elements to HTML file names and anchors. Currently the package is built by having rhevm-doc BuildRequires set on all of the documentation packages. These packages are installed on the build host and thn the spec file copies them into the rhevm-doc build root.

Other than being pretty poor form (because our source package is basically useless) it means we have to introduce a number of hacks to ensure we pick up the correct documentation, strip elements like javascript that only apply when being delivered in a publican site, etc.

On top of that we have to do the same for all localized versions which results in a lot of tagging, editing spec files, rebuilding, etc.

Recently I have filed an RFE to get publican 3 into RHEL 7 (Bug # 870201). Theoretically what this allows (and I am proposing) is for us to ship the exact (hopefully) same packages to customers as we use to display the staging server and ultimately access.redhat.com (look and feel would be like the documentation stage but we can also customize this for RHEV with a brand). This means:

- rhevm-doc to become a much smaller package, simply providing the CSV files and the publican site framework.
- rhevm-doc-en-US to be a shell that requires the "real" documentation packages.
- rhevm-doc-ja-JP to be a shell that requires the "real" Japanese documentation packages.
- and so on.

The main benefits of this are:

- More consistent look and feel of the deployed docs (3.0 was fine but 3.1 was a bit off due to hacks I had to use to get the navigation working).
- Removes the most risky hacks in rhevm-doc builds (and the other new packages being introduced wouldn't need them).
- Allows us to rely on publican's "fallback" logic when content is untranslated rather than symbolic links.
- We achieve my original goal of deploying the same packages (single sourcing). The reason we couldn't do this originally is packages built on publican > 2.5 (which we have used for quite some time) wont deploy on sites managed by publican < 2.5, RHEL 6 only shipped 2.1.

I would also like to remove the dependency on rhevm itself to allow users to install the packages on systems that are not running rhevm. Obviously all systems that *are* running rhevm would still require it to provide context sensitive help (so rhevm requires rhevm-doc, but rhevm-doc does not require rhevm). To do this I think we would also need to update the location of the docs to /usr/share/docs/ovirt-engine.

The main downsides of this are:

- The total size of an installation (rhevm-doc, rhevm-doc-en-US, and dependencies) would be larger as they would also include html-single and epub formats.
- We haven't eliminated the rel-eng overhead in the initial setup/package creation of each package.

Version-Release number of selected component (if applicable):

I'd like to target this for RHEV 4/RHEL 7 if approved (obviously the RHEL 7 component is publican 3 inclusion, which now appears to be likely).