From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1QEaW0-0000gM-GZ for garchives@archives.gentoo.org; Tue, 26 Apr 2011 05:08:48 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2766F1C01B; Tue, 26 Apr 2011 05:08:37 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 306891C004 for ; Tue, 26 Apr 2011 05:07:52 +0000 (UTC) Received: from gauss.localnet (ppp-88-217-110-183.dynamic.mnet-online.de [88.217.110.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zzam) by smtp.gentoo.org (Postfix) with ESMTPSA id AA6AE1B400F; Tue, 26 Apr 2011 05:07:50 +0000 (UTC) From: Matthias Schwarzott To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: rfc: libexec directory inconsistency Date: Tue, 26 Apr 2011 07:06:43 +0200 User-Agent: KMail/1.13.7 (Linux/2.6.37-gentoo-r3; KDE/4.6.2; x86_64; ; ) Cc: =?utf-8?q?Micha=C5=82_G=C3=B3rny?= References: <20110122170242.GA17407@linux1> <201104242143.17576.zzam@gentoo.org> <20110424214947.469feebf@pomiocik.lan> In-Reply-To: <20110424214947.469feebf@pomiocik.lan> 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="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201104260706.43981.zzam@gentoo.org> X-Archives-Salt: X-Archives-Hash: 90604f18eb4709ed3cc760f9fd3764f7 On Sonntag, 24. April 2011, Micha=C5=82 G=C3=B3rny wrote: > On Sun, 24 Apr 2011 21:43:16 +0200 >=20 > Matthias Schwarzott wrote: > > Sounds like we should fix udev ebuild and some ebuilds installing > > udev rules to not use /$(get_libdir)/udev, but plain /lib/udev. > >=20 > > I used that in believe that /lib is identical or links > > to /$(get_libdir) and multilib-strict requires it, but it seems to be > > intelligent enough to only deny 64-bit libs to go to /lib. > >=20 > > So proper udev should use /lib/udev, correct? >=20 > Do you really think it'd be fine for some systems to possibly > have /lib64 and /lib with random different contents? Regarding /lib64/udev vs. /lib/udev: I think it is fine for some time. Having some rules only in /lib64/udev when udevd looks info /lib/udev will= =20 make only these things break that depend on the extra rules. The main question is: How many systems are affected by this /lib64 is not t= he=20 same as /lib ? Matthias