Bug 884289 - Require 3.2.0 rhevm-doc-ja-JP pretrans logic to clean up Hypervisor Deployment Guide and V2V Guide location.
Require 3.2.0 rhevm-doc-ja-JP pretrans logic to clean up Hypervisor Deploymen...
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: rhevm-doc (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Stephen Gordon
Depends On: 884743 885137
  Show dependency treegraph
Reported: 2012-12-05 15:11 EST by Stephen Gordon
Modified: 2012-12-07 10:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-12-06 12:56:07 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Stephen Gordon 2012-12-05 15:11:41 EST
Description of problem:

When building the first translated context sensitive help package (rhevm-doc-ja-JP) under Bug # 837644 it was decided in consultation with engineering that we needed to provide fallback logic. That is to say where a given guide had not been translated, symbolic links were required to point to the English version of the relevant guide.

The initial rhevm-doc-ja-JP build shipped with only two guides, with the intent being to update the package around GA with the rest of the guides once they were translated replacing the fallback links.

This as it turns out was a pretty terrible idea. When it came time to package the final version I found that both YUM and RPM were unable to install the updated package because we were replacing a symlink with a directory. As a result RPM thinks rhevm-doc-ja-JP should conflict with rhevm-doc because the files, pre transaction, resolve to the same location.

This is a longstanding issue with YUM and RPM, as evidenced by a number of bugs including Bug # 646523. To make matters worse though the suggested workaround (using a %pretrans script written in LUA) doesn't resolve the issue for packages being installed via YUM because when testing the transaction yum doesn't run pretrans logic.

To get past this in a timely fashion for GA I had to update the package to:

1) For guides that had not previously been deployed rename the directories to:
2) Update the symlinks for these guides to point at the new folder instead of the en-US document.
3) RHEV-H Deployment Guide and V2V Guide which have been shipped previously had to be left is. Attempting to rename them in a manner consistent with the above exposes us to the opposite problem trying to turn a directory into a link. YUM and RPM do not support this either.

So for now we have a somewhat inconsistent, but working, rhevm-doc-ja-JP deployment but a few longer term questions that I am raising this bug for:

1) How to go about ensuring that at some point down the track we can provide an update to make the directory naming consistent.

- I think we can get out of *this* situation (but as above not the original one) using pretrans. I did write a script to attempt this and it appears in additional info but ultimately did not ship it because it was untested and relatively dangerous (as is any pretrans script). This did not seem like a good tradeoff at GA given that we had a working solution the only downside of which is some odd directory naming.
- Possible consideration, under this bug, for 3.2.

2) How to provide fallback logic for future translation packages (for other languages) without running into this issue.

- Ultimately this goes away if we move to a publican site (RHEV 4 timeframe, maybe) but in the meantime I think we need to revisit the decision not to put the fallback logic in the UIs (this was pushed back on because it was considered an undesirable location for such logic).
- Would require a new bug to move the logic, alternatively the "new" solution that resulted here is probably workable going forward. That is to say that GUIDE_NAME is always a symlink and what we change in packaging is whether it points to en-US/html/GUIDE_NAME or ja-JP/html/GUIDE_NAME.ja-JP is what we change in packaging.
- Whatever the case, we must not revert to the original solution where we tried to turn directories into symlinks and vice versa on each update to reflect translation availability.

Additional info:

This is my initial crack at pretrans logic for removing the directories, allowing us to replace them with symlinks in the transaction. Overall the idea of removing anything in pretrans is dangerous so this would need a lot of testing if we decided to run with it.

%pretrans -p <lua>
function remove_dir(d)
    for f in posix.files(d) do
        if f ~= "." and f ~= ".." then
            t = posix.stat(d.."/"..f, "type")
            if t and t == "directory" then
            elseif t and t == "link" then
            elseif t and t == "regular" then

t = posix.stat("%{docsdir}/%{locale}/html/Hypervisor_Deployment_Guide")
if t and t.type == "directory" then
t = posix.stat("%{docsdir}/%{locale}/pdf/Hypervisor_Deployment_Guide")
if t and t.type == "directory" then
t = posix.stat("%{docsdir}/%{locale}/html/V2V_Guide")
if t and t.type == "directory" then
t = posix.stat("%{docsdir}/%{locale}/pdf/V2V_Guide")
if t and t.type == "directory" then
Comment 1 Stephen Gordon 2012-12-05 15:13:05 EST
The most complicated part of the entire pretrans issue is that the code must be parsed by RPM's internal LUA implementation, which supports a bare minimum of file system I/O logic - even with the posix extensions.
Comment 2 Stephen Gordon 2012-12-06 12:56:07 EST
The residual effects of the decision to use symlinks for fallback logic in the original rhevm-doc-ja-JP package will effectively disappear as a result of the fix for Bug # 884743 where the ja-JP folder is being renamed ja.

The reason this fixes the issue is that by renaming the top level folder YUM/RPM effectively removes the entire ja-JP tree - including the errant folders/symlinks - and replaces it with the "new" ja tree which does not use the symlink logic.

We will need a new solution for fallback in the future but that should be raised as a new bug without all my redundant notes about the pretrans fix that was required if we wanted to "keep" the ja-JP folder.

Note You need to log in before you can comment on or make changes to this bug.