From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [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 14ED0138334 for ; Mon, 1 Oct 2018 20:04:34 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 61788E0A70; Mon, 1 Oct 2018 20:04:30 +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 0CEC6E0A63 for ; Mon, 1 Oct 2018 20:04:29 +0000 (UTC) Received: from sf (trofi-1-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0f::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: slyfox) by smtp.gentoo.org (Postfix) with ESMTPSA id 3B9AF335C8D for ; Mon, 1 Oct 2018 20:04:27 +0000 (UTC) Date: Mon, 1 Oct 2018 21:04:18 +0100 From: Sergei Trofimovich To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: Portage QA check for FHS/Gentoo policy paths, for top-level dirs and /usr/share/doc Message-ID: <20181001210418.75f712d5@sf> In-Reply-To: <1df93cd0-b3e7-56cf-3a29-bfaed2069e02@gentoo.org> References: <1df93cd0-b3e7-56cf-3a29-bfaed2069e02@gentoo.org> X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) 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 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: f38efb2b-5725-48cc-8d3e-065175a0f11a X-Archives-Hash: ed0222c21e52682cce375f31ec8b4072 On Mon, 1 Oct 2018 08:19:29 -0700 Zac Medico wrote: > Hi all, > > The ~arch version of portage hs a new QA check that reports installation > of files outside of directories that have been whitelisted [1]. The > current whitelist includes: > > directories common to / and /usr > ================================ > bin lib lib32 lib64 libx32 sbin > > top level directories > ================================ > boot dev etc opt srv usr var > > /usr level directories > ================================ > include libexec share src > > /usr/share/doc level directories > ================================ > /usr/share/doc/${PF} As this will break existing ebuilds I'd suggest guarding it against next EAPI. Out of top of by head the change will break at least crossdev outright. At least for two reasons: 1. building a gcc cross-compiler usually refers to $SYSROOT/sys-include. 'git grep sys-include' will show a bunch of ebuilds that create that symlinks outside the space. 2. cross-building target libc is currently done on the host's emerge and installs into /usr/$CTARGET/. I think whitelist would be able to cover these use cases as they are a function of ${CTARGET} (or $CATEGORY) value. -- Sergei