| Summary: | 'dohtml -r ${directory}/' has undocumented behavior | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Arfrever Frehtes Taifersar Arahesis <arfrever.fta> |
| Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
The council has deprecated dohtml in its 20140909 meeting, see bug 520546. :) "doins -r a/b/c/" behaves like "doins -r a/b/c", because it is the same path if "c" is a directory. Especially, the last pathname component is "c" in both cases. This is in line with the pathname resolution as specified in http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_12 and with the behaviour of coreutils (e.g. basename and dirname utilities). I fail to see in what way this would be undocumented. We also shouldn't reuse this bug (which is about dohtml) for an unrelated issue. If doins in Portage behaves differently from what is described in comment #3, I suggest opening a new bug. |
'dohtml -r ${directory}' installs e.g. /usr/share/doc/${PF}/html/${directory}/${file}. With Portage, 'dohtml -r ${directory}/' installs e.g. /usr/share/doc/${PF}/html/${file}, so it behaves similarly to 'dohtml -r ${directory}/*', but it also installs files/directories whose names start with a dot (except names equal to "." and ".."). Currently at least 138 ebuilds in gentoo-x86 rely on this behavior. If this behavior is intentional, then it should be documented.