| 1 |
On Tue, 18 Dec 2012 11:07:02 +0000 (UTC) |
| 2 |
James <wireless@×××××××××××.com> wrote: |
| 3 |
|
| 4 |
> Bryan Gardiner <bog <at> khumba.net> writes: |
| 5 |
> |
| 6 |
> |
| 7 |
> |
| 8 |
> > > I did recently put these into my package.keywords. |
| 9 |
> |
| 10 |
> > > =sys-fs/udev-196-r1 ~amd64 |
| 11 |
> > > =virtual/udev-196 ~amd64 |
| 12 |
> > > =sys-fs/udev-init-scripts-17-r1 ~amd64 |
| 13 |
> |
| 14 |
> > My guess is that you've unmasked sys-fs/udev-196 only partially. |
| 15 |
> > Portage tries to calculate the dependencies for it and finds that |
| 16 |
> > something is still missing (e.g. you need to ~amd64 more packages) |
| 17 |
> > so Portage stops with sys-fs/udev and tries to satisfy virtual/udev |
| 18 |
> > with eudev instead. |
| 19 |
> |
| 20 |
> I was cleaning up a python 3.1 mess on the system. Days |
| 21 |
> of rebuilding stuff for python 3.2 after removal of python |
| 22 |
> 3.1. and building kde-4.9.3.... |
| 23 |
> |
| 24 |
> > Try an "emerge -pv =sys-fs/udev-196-r1" and see if that gives any |
| 25 |
> > reason why Portage isn't happy with it. |
| 26 |
> |
| 27 |
> ebuild R ~] sys-fs/udev-196-r1 USE="acl gudev hwdb introspection |
| 28 |
> keymap kmod openrc -doc (-selinux) -static-libs" 0 kB |
| 29 |
> |
| 30 |
> |
| 31 |
> Since I've been following the threads on eudev, I do not want to be |
| 32 |
> out front on this issue. |
| 33 |
> |
| 34 |
> I put /var/ and /usr on the same partition as / |
| 35 |
> |
| 36 |
> I do have other partitions, such as /usr/local/video1 (etc) |
| 37 |
> |
| 38 |
> But I just put /boot / and swamp for the OS on all the gentoo |
| 39 |
> system I need. So I think I should go back to udev 181 ? |
| 40 |
> I only went to udev 196-r1 to clean up the system (late at night |
| 41 |
> just rebuilding and doing what portage wanted to keep rebuilding |
| 42 |
> everything.... |
| 43 |
> |
| 44 |
> In summary, since I put /var and /usr on the / partition |
| 45 |
> what my best (mainstream) path for udev and all the issues |
| 46 |
> (flags and other packages) to stay mainstream-stable? |
| 47 |
> |
| 48 |
> I'm not sure I fully understand what my best path forward is... |
| 49 |
|
| 50 |
/var is more often than not best kept separate from /, as the |
| 51 |
filesystem needs for those two are usually quite different. Especially |
| 52 |
with embedded devices - they can be resource constrained and don't have |
| 53 |
spare resources to waste on inefficient configs. |
| 54 |
|
| 55 |
As long as /usr is on the same partition as / you are safe for the |
| 56 |
foreseeable future. |
| 57 |
|
| 58 |
The reason for this whole / and /usr mess can be summed up in a few |
| 59 |
words: |
| 60 |
|
| 61 |
It's a bootstrap problem. |
| 62 |
|
| 63 |
Stuff could be needed at some point in the startup process before the |
| 64 |
system is in a state to present that very stuff, so one uses bootstrap |
| 65 |
techniques to make the stuff become available somehow when needed. |
| 66 |
|
| 67 |
At this point in time, all this "stuff" reduces to one simple question: |
| 68 |
"is it located on / or is it somewhere under the /usr hierarchy?" There |
| 69 |
does not seem to be any other factor involved. |
| 70 |
|
| 71 |
|
| 72 |
|
| 73 |
-- |
| 74 |
Alan McKinnon |
| 75 |
alan.mckinnon@×××××.com |
Archives