| 1 |
On 10/01/2018 11:16 AM, Michał Górny wrote: |
| 2 |
> On Mon, 2018-10-01 at 19:23 +0200, Andreas Sturmlechner wrote: |
| 3 |
>> On Montag, 1. Oktober 2018 17:48:16 CEST Michał Górny wrote: |
| 4 |
>>> On Mon, 2018-10-01 at 08:19 -0700, Zac Medico wrote: |
| 5 |
>>>> /usr/share/doc level directories |
| 6 |
>>>> ================================ |
| 7 |
>>>> /usr/share/doc/${PF} |
| 8 |
>>>> |
| 9 |
>>>> The first bug report [2] is for qt-core, which installs documentation |
| 10 |
>>>> into /usr/share/doc/${PN}-${PV} instead of /usr/share/doc/${PF} (${PF} |
| 11 |
>>>> includes ebuild revision such as -r1, -r2, and so on). |
| 12 |
>>> |
| 13 |
>>> No, it doesn't. There's no /usr/share/doc/qtcore-5.11.1 on my system. |
| 14 |
>> |
| 15 |
>> This is coming from dev-qt/qt-docs. |
| 16 |
> |
| 17 |
> Nope, still not /usr/share/doc/qt*core*-... |
| 18 |
> |
| 19 |
>> It is a problem because any other package |
| 20 |
>> building QCH API docs with cross-references to Qt API needs to install below |
| 21 |
>> this path, and will generate the same QA warning (currently kde-frameworks/* |
| 22 |
>> does this). |
| 23 |
> |
| 24 |
> Yes. That is why I believe that hardcoding the exception in every |
| 25 |
> package is simply wrong. Wouldn't it be cleaner to account for the path |
| 26 |
> in the QA check? |
| 27 |
|
| 28 |
There may be cases where we want to fix the ebuild to use |
| 29 |
/usr/share/doc/${PF} though, right? |
| 30 |
-- |
| 31 |
Thanks, |
| 32 |
Zac |
Archives