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 1RFDcl-0001dd-3y for garchives@archives.gentoo.org; Sat, 15 Oct 2011 23:26:39 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DB1D321C149; Sat, 15 Oct 2011 23:26:29 +0000 (UTC) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.122]) by pigeon.gentoo.org (Postfix) with ESMTP id 4B0E021C0EE for ; Sat, 15 Oct 2011 23:25:26 +0000 (UTC) X-Authority-Analysis: v=2.0 cv=TqhkdUrh c=1 sm=0 a=xvUQ5II7JMRnhGkbsebX1A==:17 a=GBs5CIn6x6sA:10 a=W-XbvpvmNHQA:10 a=6WvLBrxrMboA:10 a=wPDyFdB5xvgA:10 a=IkcTkHD0fZMA:10 a=yrL_-9eVBU3B4RB-0XgA:9 a=MB37qdySGXA4LiM8erwA:7 a=QEXdDO2ut3YA:10 a=xvUQ5II7JMRnhGkbsebX1A==:117 X-Cloudmark-Score: 0 X-Originating-IP: 97.102.250.187 Received: from [97.102.250.187] ([97.102.250.187:47330] helo=basement.kutulu.org) by cdptpa-oedge01.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 5C/DA-15901-5661A9E4; Sat, 15 Oct 2011 23:25:25 +0000 Received: from localhost (basement.kutulu.org [127.0.0.1]) by basement.kutulu.org (Postfix) with ESMTP id 90F9D112007; Sat, 15 Oct 2011 19:25:25 -0400 (EDT) X-Virus-Scanned: amavisd-new at kutulu.org Received: from basement.kutulu.org ([127.0.0.1]) by localhost (basement.kutulu.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPkVG7ft18NU; Sat, 15 Oct 2011 19:25:24 -0400 (EDT) Received: from [192.168.69.4] (wombat.kutulu.org [192.168.69.4]) by basement.kutulu.org (Postfix) with ESMTP id E8BC0112006; Sat, 15 Oct 2011 19:25:24 -0400 (EDT) Message-ID: <4E9A1665.7010303@kutulu.org> Date: Sat, 15 Oct 2011 19:25:25 -0400 From: Mike Edenfield User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20110929 Thunderbird/8.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org CC: =?UTF-8?B?Q2FuZWsgUGVsw6FleiBWYWxkw6lz?= Subject: Re: [gentoo-user] Apologize to everyone for my nonprofessional References: <1474337.CKuYS0Cz6D@pc> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: 2ac3e79efa2cc46b54779ab8a3c56ca7 On 10/15/2011 4:42 AM, Canek Pel=C3=A1ez Vald=C3=A9s wrote: > Which one? That /var is not going into /? It's not disinformation, it > is th true. If not, please be so kind of showin one single developer > reference that says so. One. Single. One. > > Email, blog post, wiki, you choose it. But one single one. I don't think anyone is claiming that there are *currently*=20 plans to require /var, either on / or via initramfs. The claim being made is that /var suffers from the exact=20 same problem that /usr does, with regard to udev, namely=20 that arbitrary programs running from within udev rules could=20 (and some do) require /var to be present to function. Thus,=20 the arguments being applied to /usr *currently* can be=20 applied equally to /var, once it becomes an issue. The classic example being given is a bluetooth keyboard: to=20 make a bluetooth keyboard available, udev executes a rule=20 which requires /var/bluetooth to be present. (Certain other=20 rules similarly require data from /var, such as sound cards=20 or printers.) The extremely logical deduction being made is as follows: Some udev rules require /usr to be preset to properly=20 execute. The solution favored by the udev maintainer is to=20 simply make /usr always required for udev to run. Running=20 udev without /usr present will become unsupported. Similarly, some udev rules require /var to be present to=20 properly execute. The solution that will be favored by the=20 udev maintainer, when such an issue is raised, is most=20 likely going to be similar to the solution proposed for=20 /usr: the mandating of /var being present before udev runs.=20 Running udev without /var present will most likely become=20 unsupported. Programs designed to run out of /bin expect to be run=20 without any other locations present. Programs designed to=20 run out of /usr/bin generally assume that the rest of the=20 system, including /var, is available for use. You can't have=20 one without the other. --Mike