| Summary: | INFODIR regens rename dir to dir.old but do nothing else if no .info files are found | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | mike <mail_acct> |
| Component: | Unclassified | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 181949 | ||
Is this still even remotely relevant? This is fixed in svn r7594 and released in 2.1.3.5. |
Possibly because of one of my USE vars ("emacs" maybe?) I see following "% emerge <pkg>" the message "Regenerating GNU info directory index." One of the things as a result of this is having my own personally specified top-level dir file renamed to dir.old. Apparently it's parsing my INFOPATH to locate it. This behavior is entirely inappropriate and more than just unnecessary. GNU's Info is designed to support numerous dir files all coexisting together. But since I see dir and dir.old in info dirs it's possible emerge just doesn't like the fact that it found a dir file (from my shell INFOPATH) in a directory which has no *info files. I also see this "Regenerating..." message whether or not the source just installed has Info files. Reproducible: Always Steps to Reproduce: 1. Not known if "Regenerating..." is default behavior or if it requires a certain USE var be set; 2. (Using my personal example, using tcsh) create ~/.elisp and copy a valid dir file there 3. Reset shell INFOPATH such that ~/.elisp is first element 4. emerge <any pkg> Actual Results: Once emerge completes ~/.elisp dir will be renamed ~/.elisp/dir.old Expected Results: That it should not be renaming dir.