On Tue, 18 Dec 2012 11:07:02 +0000 (UTC) James <[email protected]> wrote:
> Bryan Gardiner <bog <at> 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 [email protected]
