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 1R3BfT-0005sJ-I6 for garchives@archives.gentoo.org; Mon, 12 Sep 2011 18:55:43 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 05CCD21C0B7; Mon, 12 Sep 2011 18:55:33 +0000 (UTC) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by pigeon.gentoo.org (Postfix) with SMTP id 132FF21C078 for ; Mon, 12 Sep 2011 18:54:09 +0000 (UTC) Received: (qmail invoked by alias); 12 Sep 2011 18:54:09 -0000 Received: from p5B083DA8.dip.t-dialin.net (EHLO pc.localnet) [91.8.61.168] by mail.gmx.net (mp020) with SMTP; 12 Sep 2011 20:54:09 +0200 X-Authenticated: #13997268 X-Provags-ID: V01U2FsdGVkX186xvYJJPY6Sgrk3moRErRcLjRAtsM9Aagt+2jxZ1 MGlwNVL2zPUKAf From: Michael Schreckenbauer To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] udev + /usr Date: Mon, 12 Sep 2011 20:54:12 +0200 Message-ID: <4544724.YAtd56odc4@pc> User-Agent: KMail/4.7.1 (Linux/2.6.38-gentoo; KDE/4.7.1; x86_64; ; ) In-Reply-To: References: <20110912150248.GB3599@acm.acm> <6790011.zDlzockbj4@pc> 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 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Y-GMX-Trusted: 0 X-Archives-Salt: X-Archives-Hash: b713a78f1b9e12c90ae9b938fea0ab23 On Monday, 12. September 2011 14:26:13 Canek Pel=E1ez Vald=E9s wrote: > On Mon, Sep 12, 2011 at 12:52 PM, Michael Schreckenbauer =20 wrote: > > On Monday, 12. September 2011 12:42:00 Canek Pel=E1ez Vald=E9s wrot= e: > >> On Mon, Sep 12, 2011 at 12:21 PM, Dale wrot= e: > >> > You say it was disinformation about /var. Care to explain why m= e > >> > and > >> > one > >> > other person read the same thing? It was mentioned on -dev. I > >> > was > >> > pretty sure it was and then another person posted they read the > >> > same. > >> > So, I'm almost certain it was said at this point. Surely we > >> > can't > >> > both be wrong. > >>=20 > >> Where did you guys read it? Who said /var could not be in its own > >> partition anymore? What piece of code stops working if /var it's i= n > >> its own partition? Who is proposing that a separated /var will not= be > >> supported in the future? > >=20 > > Just have a look in /var/lib/* for example. >=20 > I did mentioned /var/lib two paragraphs below. Do you guys respond an= > email while you read it? Of course I read the mails I answer! You wrote: "var/lib usually stores whole databases." And I said, have a look into it. You did? Could you explain to me, what /var/lib/alsa has to do with databases? Or /var/lib/dbus? > > You guarantee, that nothing of this stuff is or will be needed by u= dev? >=20 > I don't have to. Contrary to most of the guys here (I'm not saying yo= u > are one of them), I don't see the proposed change as "irrational". It= > makes complete sense (you actually mention several reasons why it > makes sense in others emails here to Alan and others). No, I don't say, "it makes sense", because it does not. I know, *why* this is done, that's something completly different from "= making=20 sense". What makes sense is fixing udev. Marking devices as "not presen= t",=20 because scripts are not available, is bad design. > Requiring /var to be on / would not make sense. Yes. Makes no sense. And now *look* into /var/lib. You guarantee, nothing in there is or will be needed by udev? > Even more: then the > idea of /run and /lock on / would be completely insane, if eventually= > they would require a non separated /var. The proposal of /run and > /lock on / is exactly to allow /var to be on its own partition on te > foreseeable future. >=20 > >> The thread I post talks about /var/run and /var/lock needing to be= > >> symbolic links to /run and /lock, but AFAIK (and I tend to follow = this > >> sort of things) /var not only can be in its own partition, it is t= he > >> recommended setup. > >=20 > > Yes. Until this dev has his next brilliant idea. >=20 > Give them some credit. This whole lot of changes is not the impositio= n > of some crazy dev. Is the result of years of the Open Source stack > evolving, and writing the code that implements a design. I give him credits. I don't think, he is an idiot. But I really think, = the=20 design is bad and needs to be fixed. Regards, Michael