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 1R3AVj-0006GK-1C for garchives@archives.gentoo.org; Mon, 12 Sep 2011 17:41:35 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0265E21C0B0; Mon, 12 Sep 2011 17:41:25 +0000 (UTC) Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id DC271E0539 for ; Mon, 12 Sep 2011 17:40:00 +0000 (UTC) Received: by bkbzt12 with SMTP id zt12so2454022bkb.40 for ; Mon, 12 Sep 2011 10:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=+eueGQDNR9vxoJc+TG1mzvRW947YB7exLi4x7pNTOpo=; b=k+B3MTxEo8wfxAUEPktDeT0hCA4JQAr0XB22bo4/VAoNiQ4ABrixDDwF6F6UIssRBg VrAVCbsj+edVeeiXtA6L5Ufrr01BJiBpIqif4ALmv8QOoETh4bdWp9TNODGKT3BNlAep BVRHIjTVVvmj8s3bmdfUJDMJHepA3cmNUzXmk= 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 Received: by 10.204.157.1 with SMTP id z1mr1179337bkw.277.1315849199991; Mon, 12 Sep 2011 10:39:59 -0700 (PDT) Received: by 10.204.155.79 with HTTP; Mon, 12 Sep 2011 10:39:59 -0700 (PDT) In-Reply-To: <20110912171737.GC3599@acm.acm> References: <20110912150248.GB3599@acm.acm> <2874055.6JTUjtRtEH@pc> <20110912171737.GC3599@acm.acm> Date: Mon, 12 Sep 2011 13:39:59 -0400 Message-ID: Subject: Re: [gentoo-user] udev + /usr From: Michael Mol To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: 335eea3170db716c78c5b3ffc9105ada On Mon, Sep 12, 2011 at 1:17 PM, Alan Mackenzie wrote: > On Mon, Sep 12, 2011 at 05:33:34PM +0200, Michael Schreckenbauer wrote: >> On Monday, 12. September 2011 15:02:48 Alan Mackenzie wrote: > >> > Hope nobody minds me starting a new thread with an accurate name. > >> > Which version of udev is it that has this nauseating feature of needin= g >> > /usr loaded to boot? > >> > Somewhere in that version's source will be several (or lots of) "/usr"= . >> > Just how difficult is it going to be to replace "/usr/bin" with "/bin" >> > throughout the source? > >> you misunderstood something. udev is able to run arbitrary scripts. Some= of >> those scripts are located in /usr/* or need something there. I doubt you= will >> find references to /usr in the udev-sources. > > Well, I'm a hacker. =C2=A0udev is free source, therefore fair game. =C2= =A0I don't > intend to put up with this nonsense without a fight. =C2=A0As far as I ca= n > make out, this is just one guy, Kay Sievers, who's on a power trip. =C2= =A0Are > there any indications at all that he actually talked to anybody in the > wide world before making such a far reaching decision? udev has always been able to run arbitrary scripts. The trouble is that the arbitrary scripts other packages provide sometimes call for things under /usr. If I've read messages over the last couple days correctly, I think the recent change is that some stuff udev *directly* depends on, as part of the udev package itself, is being moved into /usr. My best guess is that this allows udev to force the issue; it gets blamed for other packages not loading correctly (when those other packages put things in places which may or may not be available yet), so the udev developer chose to force systems to have all of /usr available before udev is run. The first step in a clean solution, IMO, is to revert that change. The second step is to fix the 'silent failure' problem for packages which depend on /usr before /usr is available. You might do it with a dependency tree which would control the order things are done, but some packages may not be able to know what they depend on. (take dhcpd, for example; it doesn't know what kind of weird magic someone else put in exit-hooks) Another solution would be to have a retry queue like what Schreckenbauer (sorry; too many Mikes) was suggesting. It might be difficult to discern a rulescript failure that stems from another rule needing to be run first versus a rulescript failure that stems from, e.g. a syntax error. --=20 :wq