From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 7681F1381F4 for ; Mon, 13 Aug 2012 21:14:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0D8E2E08AF for ; Mon, 13 Aug 2012 21:14:37 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id B2AB221C05B for ; Mon, 13 Aug 2012 18:29:05 +0000 (UTC) Received: from [192.168.1.43] (unknown [96.231.195.182]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: tetromino) by smtp.gentoo.org (Postfix) with ESMTPSA id EC1381B401A for ; Mon, 13 Aug 2012 18:29:04 +0000 (UTC) Message-ID: <1344882542.23246.3.camel@rook> Subject: Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423) From: Alexandre Rostovtsev To: gentoo-dev@lists.gentoo.org Date: Mon, 13 Aug 2012 14:29:02 -0400 In-Reply-To: <502943F0.3050401@flameeyes.eu> References: <5029318A.3050706@gentoo.org> <502943F0.3050401@flameeyes.eu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4 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-Transfer-Encoding: 8bit X-Archives-Salt: ba6feea2-8754-4462-92fe-830758de07e2 X-Archives-Hash: eefb4c87e960ffb675bbbeb1ba13f1d9 On Mon, 2012-08-13 at 11:14 -0700, Diego Elio Pettenò wrote: > Beside the fact that these would probably have looked better in > /usr/libexec See Kay Sievers's comment at https://bugs.freedesktop.org/show_bug.cgi?id=51617 : "/usr/lib// is a directory like /usr/libexec/ or even /bin. It shares absolutely zero things with the arch-specific $libdir ,or lib64/. /usr/lib// is the canonical "application private directory". It has the multi-lib or arch-specific rules as /bin. It just happens to be the same directory as $libdir for 32bit installations in the classic non-multi-arch layout, which might go away over time, but that is absolutely no reason to symlink it away. Having /lib pointing to /lib64 is plain wrong, and should not explicitly be supported by upstream build systems. If it happens to be that libexecdir works for that, then it's fine, but it is surely not treated as a bug if it isn't." -Alexandre