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 6542C1381F3 for ; Tue, 18 Dec 2012 09:05:37 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5145721C131; Tue, 18 Dec 2012 09:05:28 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 02E2B21C126 for ; Tue, 18 Dec 2012 09:04:55 +0000 (UTC) Received: from [192.168.1.2] (pool-173-77-245-118.nycmny.fios.verizon.net [173.77.245.118]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id 640D933DAFD for ; Tue, 18 Dec 2012 09:04:54 +0000 (UTC) Message-ID: <50D030DA.1020400@gentoo.org> Date: Tue, 18 Dec 2012 04:01:14 -0500 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121128 Thunderbird/10.0.11 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: eudev project announcement References: <20121215185843.GA8156@waltdnes.org> <20121215203359.4552d807@pomiocik.lan> <50CCDAC1.2080405@gentoo.org> <20121217104022.GA27716@bkor.dhs.org> <50CEFD54.7020801@gentoo.org> <20121217132500.GA29679@bkor.dhs.org> <50CF2C46.8040206@gentoo.org> <20121217194842.GA3103@bkor.dhs.org> <14fbeea8-8434-451e-a611-80e23fb36b38@email.android.com> <20121217213159.GA9719@kroah.com> <20121217232343.GA22852@linux1> In-Reply-To: <20121217232343.GA22852@linux1> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig357672B964F9ECD80954BF22" X-Archives-Salt: 469f43f7-b53f-4408-b8af-c11b1fbbe654 X-Archives-Hash: a8bc7b4ded5c1937da3c288932c9348e This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig357672B964F9ECD80954BF22 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/17/2012 06:23 PM, William Hubbs wrote: > On Mon, Dec 17, 2012 at 01:31:59PM -0800, Greg KH wrote: >> On Mon, Dec 17, 2012 at 09:03:40PM +0100, J. Roeleveld wrote: >>> Olav Vitters wrote: >>> >>>> On Mon, Dec 17, 2012 at 09:29:26AM -0500, Richard Yao wrote: >>>>> As I said in an earlier email, Lennart Poettering claims that it do= es >>>>> not work. We are discussing some of the things necessary to make it= >>>> work. >>>> >>>> Just to repeat: >>>> In this thread it was claimed that a separate /usr is not supported = by >>>> systemd/udev. >>>> >>>> A case which works with latest systemd on various distributions. I >>>> checked with upstream (not Lennart), and they confirmed it works. I = can >>>> wait for Lennart to say the same, but really not needed. >>>> >>>> I assume this will again turn into a "but I meant something else". >>> >>> Olav. >>> >>> Lennart has stated that he considers a seperate /usr without init* br= oken. >> >> Yes, as do I, and so do a lot of other developers. >> >> But that is a system configuration issue, not a systemd issue, please >> don't confuse the two. >> >>> This has worked correctly in the past. >> >> Define "past" please. >> >> Note, it's still broken, I have yet to see any upstream fixes to resol= ve >> all of the issues that are involved here with "fixing" this up. >> >> Yes, as always, for some subset of users, you can be lucky and it will= >> work for them, but those systems are getting rarer and rarer these day= s, >> as the rest of upstream (not systemd here) are moving on and not doing= >> anything to change their behavior for this topic. >> >>> The direction udev development is going, according to Lennart, is to >>> make that impossible and he refuses to fix this regression. >> >> Again, this has NOTHING to do with udev or systemd, as has been pointe= d >> out numerous times. I understand your _wish_ that it would have >> something to do with it, but that will not change the facts, sorry. >> >>> I am really happy with this project and intend on testing it once >>> requests for this appear in the eudev mailing list. >> >> Good luck, the root problems still remain, and nothing that eudev ever= >> does can resolve that, sorry. >> >> Can this topic finally be put to rest please? There is a whole web pa= ge >> devoted to this topic, why do people blindly ignore it? > =20 > This is a very good question. >=20 >> Again, a separate /usr without an initrd has NOTHING to do with system= d >> or udev, with the minor exception that Gentoo's packaging of those >> programs _might_ have an issue, but that is Gentoo's issue, NOT >> upstream's issue. >> >> If anyone involved with eudev, or is involved with the Gentoo Council >> thinks that the previous paragraph is incorrect, they are flat out >> wrong. > =20 > This all started with the April 2012 council meeting when it was pushed= > through that separate /usr without an initramfs is a supported > configuration, so yes, the previous council started this issue. >=20 > Also, yes, eudev believes they will be able to fix it. >=20 > I am another one who has been pointing out how this is wrong multiple > times but my statements about it are falling on deaf ears. >=20 > William >=20 I have also explained how we can fix this multiple times and I can say that my explanations have been ignored. The eudev project's solution to this can be summarized in the few sentences that I said in a response to gregkh (after you wrote your email): >I reject >the notion that there be a single rules directory. That opens the door >to having a second directory on /usr that enforce the requirement that >rules that depend on /usr execute after /usr is mounted. The only argument that has been made against it involves libraries that cross the /usr boundary. I consider such situations to be avoidable. There has been no other argument made against this approach and I am quite confident that it is sound. Furthermore, it satisfies the request of various users to support a separate /usr mount without an initramfs. Satisfying that seems to me to be a worthwhile goal and it is one that I and others believe that we can do. --------------enig357672B964F9ECD80954BF22 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQ0DDdAAoJECDuEZm+6ExkvtkP+QFZJ9Vkk1Z5A43rCQyBC/DK WZ57yOVIa7RTESEIaY2pUbeJ/qSAWC7edYLhUmcc7sr5GHQM3iqzL/1dGZDheJgL MiN/6HPEu6mQFgqR4w/8k+kBSkTHSxY4D9o23ZtQ5JG+dInyu86tGYayCA+ru/Ot yHvRINIRESs7fhXLrQAlefN3p7xjbO/jCspNGALkmDiAWrLgvhilHz/9mjCnvR/g qwObPaDoxQbCOUQnLqVPb/xtYP39bjq7sl6ZjjvIiMhh1HQCjyRRoTWvC68f7Y0b NkWlxlrrN3CcvSUgWGQqEUDHuS0s4rnabybHoTILXMkIqA3V67tzYs+UQg8lisMT 0vlCxqtQriRjpyMIpRjZ4T0ToU2eW+os6yeiUMEFxoMY4XXEjaysskzf5HZ7rv97 w2LlYA0Ii2mAVr1L/j6HJ8b4O5EPmxMqu/FWjbQ5pwRexGXIWzvz8UldXf1lMzG7 NorVzwopfOBhWF4YW+/z7nd2li7iOpcyo2+6Pje6Rha2z1bBB6lJeyJ2Q+k99IcD tUuMgEj8TeKx8e9ALYFgPUrDTbZRk2ufTACZXySKo2YeBsdZ3J3cYbgEUJNH7Eej jAciP/Qq6q6gTyFlOAxtCUqSnlfLLUsuT596SnGi5fCOdZvNM9hRQiM0Uc8rqhEx o6RFkuXIyiMDwkdCm/Sy =r7XN -----END PGP SIGNATURE----- --------------enig357672B964F9ECD80954BF22--