From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.windriver.com ([147.11.1.11]) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1T907U-0002WH-VP for openembedded-core@lists.openembedded.org; Tue, 04 Sep 2012 22:53:13 +0200 Received: from ALA-HCA.corp.ad.wrs.com (ala-hca [147.11.189.40]) by mail.windriver.com (8.14.5/8.14.3) with ESMTP id q84KemBY025426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Sep 2012 13:40:48 -0700 (PDT) Received: from msp-dhcp18.wrs.com (172.25.34.18) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.2.309.2; Tue, 4 Sep 2012 13:40:47 -0700 Message-ID: <5046674F.6080908@windriver.com> Date: Tue, 4 Sep 2012 15:40:47 -0500 From: Mark Hatle Organization: Wind River Systems User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Burton, Ross" References: <4976204.OdG2Ohk3KU@helios> <1346267538.4396.38.camel@x121e.pbcl.net> <1346278937.4396.57.camel@x121e.pbcl.net> <1346423384.2673.102.camel@phil-desktop> <1346428885.16485.29.camel@ted> <43FF08E0-8A1F-4B64-9552-D5C68A207D0C@gmail.com> <50462C35.6000400@windriver.com> <50465A0D.6090309@windriver.com> In-Reply-To: Cc: openembedded-core@lists.openembedded.org Subject: Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 20:53:13 -0000 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit On 9/4/12 3:06 PM, Burton, Ross wrote: > On 4 September 2012 20:44, Mark Hatle wrote: >>> So that's a false positive, and libgudev can be moved back into /usr >>> where it belongs? >> >> The gobject linkage into udev is either the result of a newer version of >> udev, different configuration options or "something else". The version >> we're using from the Denzil branch did not generate this failure. (maybe >> the check was in error?) > > gudev is relatively new, so probably isn't in the Denzil udev. It > would be interesting to see if it's used in early boot or not (I > suspect not, as it depends on GObject), and only selectively move > parts of udev to /lib as required instead of forcing everything to > move. Ya, understanding how it's used and when.. it should be much easier to make a good choice. I know in the past I've been able to break apart things like this. --Mark > Ross >