Re: [gentoo-dev] RFC: Portage QA check for FHS/Gentoo policy paths, for top-level dirs and /usr/share/doc

[Zac Medico]

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

Until this QA check has adjustable whitelist support, we can consider it
an unstable work in progress. Therefore, I'd like for the QA team to
move it gentoo/metadata/install-qa-check.d/08gentoo-paths until it has
matured. It's safe to commit it to the gentoo repository now, and it
will become active when portage's internal copy is removed. I've filed
this bug report to track progress:

https://bugs.gentoo.org/667604
-- 
Thanks,
Zac