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 31F0F1381F3 for ; Tue, 18 Dec 2012 13:08:11 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A771221C125; Tue, 18 Dec 2012 13:07:56 +0000 (UTC) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C26C021C0CD for ; Tue, 18 Dec 2012 13:06:48 +0000 (UTC) Received: by mail-bk0-f53.google.com with SMTP id j5so303620bkw.26 for ; Tue, 18 Dec 2012 05:06:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:subject:message-id:in-reply-to:references :organization:x-mailer:mime-version:content-type :content-transfer-encoding; bh=B4eZpMgWmAgnFjIfFT8k0+mUZabrndammlt40ptWoN8=; b=aPL/vaVCNi1AOOkXJxgBB4hj1D9rrK+HqWjuRFazPw0MQ2uiN0ISlmXQZSPw2mUSVl vcHEHgSDgp5452xWBpdFSr8vofYyH/e2nAUeoZqwbLUwzMzYqpZci/xRbaqIGUYEQFsv HvaWDf2OevYDhDt5axGeI340fXt0MWzF6GCZ0APnCN/ZUisvrevoZk0yfO8aKrizqiG+ Xf/iLiX2tUJjWZCp10WHB7UDPQCA5Jx/rIB2fx96sVkb8m2iXkgeA5/65plXwVJebosO 9PBHWL54apYN5CCxvTL7udhvTwTf/iN0DghMralgiG0R0wUez9ZIB9DZbQHHi35Jh4qe igVQ== X-Received: by 10.204.9.19 with SMTP id j19mr688998bkj.96.1355836007235; Tue, 18 Dec 2012 05:06:47 -0800 (PST) Received: from khamul.example.com (dustpuppy.is.co.za. [196.14.169.11]) by mx.google.com with ESMTPS id 18sm1245826bkv.0.2012.12.18.05.06.44 (version=SSLv3 cipher=OTHER); Tue, 18 Dec 2012 05:06:45 -0800 (PST) Date: Tue, 18 Dec 2012 15:03:10 +0200 From: Alan McKinnon To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: eudev Message-ID: <20121218150310.4af801e6@khamul.example.com> In-Reply-To: References: <20121216125746.4fbd681f@khumba.net> Organization: Internet Solutions X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.14; x86_64-pc-linux-gnu) 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-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 2d201fe0-7ab8-4280-ba45-02e3b68ed271 X-Archives-Hash: 757dd667aef78908d585628d50233903 On Tue, 18 Dec 2012 11:07:02 +0000 (UTC) James wrote: > Bryan Gardiner khumba.net> writes: > > > > > > I did recently put these into my package.keywords. > > > > =sys-fs/udev-196-r1 ~amd64 > > > =virtual/udev-196 ~amd64 > > > =sys-fs/udev-init-scripts-17-r1 ~amd64 > > > My guess is that you've unmasked sys-fs/udev-196 only partially. > > Portage tries to calculate the dependencies for it and finds that > > something is still missing (e.g. you need to ~amd64 more packages) > > so Portage stops with sys-fs/udev and tries to satisfy virtual/udev > > with eudev instead. > > I was cleaning up a python 3.1 mess on the system. Days > of rebuilding stuff for python 3.2 after removal of python > 3.1. and building kde-4.9.3.... > > > Try an "emerge -pv =sys-fs/udev-196-r1" and see if that gives any > > reason why Portage isn't happy with it. > > ebuild R ~] sys-fs/udev-196-r1 USE="acl gudev hwdb introspection > keymap kmod openrc -doc (-selinux) -static-libs" 0 kB > > > Since I've been following the threads on eudev, I do not want to be > out front on this issue. > > I put /var/ and /usr on the same partition as / > > I do have other partitions, such as /usr/local/video1 (etc) > > But I just put /boot / and swamp for the OS on all the gentoo > system I need. So I think I should go back to udev 181 ? > I only went to udev 196-r1 to clean up the system (late at night > just rebuilding and doing what portage wanted to keep rebuilding > everything.... > > In summary, since I put /var and /usr on the / partition > what my best (mainstream) path for udev and all the issues > (flags and other packages) to stay mainstream-stable? > > I'm not sure I fully understand what my best path forward is... /var is more often than not best kept separate from /, as the filesystem needs for those two are usually quite different. Especially with embedded devices - they can be resource constrained and don't have spare resources to waste on inefficient configs. As long as /usr is on the same partition as / you are safe for the foreseeable future. The reason for this whole / and /usr mess can be summed up in a few words: It's a bootstrap problem. Stuff could be needed at some point in the startup process before the system is in a state to present that very stuff, so one uses bootstrap techniques to make the stuff become available somehow when needed. At this point in time, all this "stuff" reduces to one simple question: "is it located on / or is it somewhere under the /usr hierarchy?" There does not seem to be any other factor involved. -- Alan McKinnon alan.mckinnon@gmail.com