From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (unknown [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id AA751138334 for ; Sun, 27 Jan 2019 13:58:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E0E54E111C; Sun, 27 Jan 2019 13:58:42 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 909D9E1114 for ; Sun, 27 Jan 2019 13:58:42 +0000 (UTC) Received: from tuxk10.localnet (91-119-2-20.dsl.dynamic.surfer.at [91.119.2.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: asturm@gentoo.org) by smtp.gentoo.org (Postfix) with ESMTPSA id 934E0335C8F; Sun, 27 Jan 2019 13:58:40 +0000 (UTC) From: Andreas Sturmlechner To: gentoo-dev@lists.gentoo.org Cc: =?utf-8?B?TWljaGHFgiBHw7Nybnk=?= Subject: Re: [gentoo-dev] RFC: Portage QA check for FHS/Gentoo policy paths, for top-level dirs and /usr/share/doc Date: Sun, 27 Jan 2019 14:58:34 +0100 Message-ID: <59565022.tOID2UdrHk@tuxk10> In-Reply-To: <1538417788.1095.10.camel@gentoo.org> References: <1df93cd0-b3e7-56cf-3a29-bfaed2069e02@gentoo.org> <2733265.gtnf6FpWjD@tuxbrain> <1538417788.1095.10.camel@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 7e6361ee-7390-4556-96ed-8b0b2e4dab2b X-Archives-Hash: 82e581cfb4413753e292d74ebb80b91b On Montag, 1. Oktober 2018 20:16:28 CET Micha=C5=82 G=C3=B3rny wrote: > > 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). >=20 > 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? What's the current status of this? I'd like to know if there's going to be = a=20 whitelist or QA_ var to put into kde5.eclass, if not, I can also simply=20 (EAPI-7-)move kde handbook directory out of /usr/share/doc into /usr/share/ kde-doc or similar and be done with it. Regards, Andreas