1 |
On 11/14/06, felix@×××××××.com <felix@×××××××.com> wrote: |
2 |
> I have a ~amd64 system on which I am trying to emerge world. |
3 |
> |
4 |
> First, what are the proper options to pass to this command? |
5 |
|
6 |
Nobody here can actually answer that question, because it depends on |
7 |
what, exactly, you want to do. However, some common option |
8 |
cominations, and their effect, would be: |
9 |
|
10 |
"emerge world": updates only packages that are explicitly listed in |
11 |
/var/lib/portage/world. |
12 |
|
13 |
"emerge --update world": same as above, but also updates *direct* |
14 |
dependancies of those packages. |
15 |
|
16 |
"emerge --deep --update world": same as above, but updates *all* dependancies. |
17 |
|
18 |
"emerge --deep --update --newuse world": same as above, but will also |
19 |
rebuild packages where the defined or configured USE flags have |
20 |
changed. |
21 |
|
22 |
As for which is the most appropriate for you, well: |
23 |
|
24 |
--deep ensures you get all of the very latest updates for everything. |
25 |
Well, /almost/ everything [1]. The downside of this is that you have |
26 |
a lot more updating to do, and library updates can break dynamic |
27 |
linking of some programs requiring them to be rebuilt with |
28 |
revdep-rebuild. Not surprisingly, opponents of --deep typically cite |
29 |
system and ABI stability as arguments against using --deep. |
30 |
|
31 |
--newuse is almost always a good idea, and certainly "required" after |
32 |
making changes to your USE in make.conf or package.use. |
33 |
|
34 |
> Second, when I try emever -pve world, I get the following complaints: |
35 |
> |
36 |
> Calculating world dependencies |
37 |
> ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ... done! |
38 |
> [blocks B ] kde-base/kde-env (is blocking kde-base/kdelibs-3.5.5-r5) |
39 |
> [blocks B ] >=kde-base/kdelibs-3.5.4-r2 (is blocking kde-base/kde-env-3-r4) |
40 |
|
41 |
kde-env is not required (and is in fact incompatible) with the new |
42 |
kdelibs. Do "emerge -C kde-env" to remove kde-env and resolve these |
43 |
|
44 |
> [blocks B ] www-client/mozilla (is blocking www-client/seamonkey-1.0.6) |
45 |
|
46 |
see below... |
47 |
|
48 |
> [blocks B ] <dev-python/pygtk-2.9 (is blocking dev-python/pygobject-2.12.2) |
49 |
|
50 |
You have some version of pygtk earlier than 2.9 installed, which |
51 |
conflicts (e.g. by installing duplicate files, etc) with pyobject. |
52 |
Basically, you need a ~arch version of pygtk to go with your ~arch |
53 |
pyobject. |
54 |
|
55 |
> This happens aperiodically. Some new package obsoletes another |
56 |
> package, but nothing documents it, nothing tells me what to do. |
57 |
|
58 |
/usr/portage/cate-gory/package/ChangeLog should document when the |
59 |
block was added, usually with a bug# that you can reference on |
60 |
bugs.gentoo.org. But as far as telling you what to do, well, *gentoo* |
61 |
*doesn't* *do* *that*.....*ever*! ;-P |
62 |
|
63 |
How you handle a block is entirely up to you. |
64 |
|
65 |
> Do I unmerge the existing package and install the new one? |
66 |
|
67 |
That is certainly one option. You could also mask the new one in |
68 |
/etc/portage/package.mask. If it is a version block, you might need |
69 |
to update to a newer (or downgrade to an older) version of a package. |
70 |
|
71 |
> 3. Mozilla vs Seamonkey. I tried Seamonkey a couple of times, and it |
72 |
> crashed so often and so quickly that I reverted to mozilla. Now it |
73 |
> seems there are quite a few packages which insist on seamonkey and |
74 |
> are not satisfied with mozilla. |
75 |
|
76 |
You will have to give an example of this. I certainly don't have |
77 |
seamonkey installed on either of my ~arch systems, and I have a good |
78 |
number of packages installed on both. |
79 |
|
80 |
If the packages have USE flags, check them. Something with a |
81 |
"firefox" flag might use that to prefer firefox over seamonkey. |
82 |
Something else with a "no-seamonkey" flag...well, guess what that |
83 |
does. TIP: add --verbose --pretend to your emerge commands to see the |
84 |
USE flags and changes. And add --tree to see what is pulling in |
85 |
seamonkey. |
86 |
|
87 |
> Why do some packages explicitly care about seamonkey? Shouldn't |
88 |
> they be pretty much the same? Shouldn't the dependencies be happy |
89 |
> with either one? |
90 |
> |
91 |
> In the meantime, is there some way to convince emerge that |
92 |
> seamonkey has been installed and to not get its knickers in a |
93 |
> twist? |
94 |
|
95 |
man emerge, /package.provided. But this is probably overkill, I think |
96 |
you just don't have your USE flags set the way you want. |
97 |
|
98 |
|
99 |
|
100 |
|
101 |
I suppose I could always unmerge mozilla, emerge world, |
102 |
> unmerge seamonkey, and emerge mozilla again, but I get tired of |
103 |
> having to kick out half a dozen packages like totem |
104 |
|
105 |
totem depends on seamonkey if you have USE="+nsplugin -firefox"... |
106 |
|
107 |
> gedit, |
108 |
|
109 |
No direct dependancy on seamonkey here |
110 |
|
111 |
> gnome-base |
112 |
|
113 |
No such package...did you mean gnome-base/gnome? If so, again, no |
114 |
direct depend here |
115 |
|
116 |
> epiphany |
117 |
|
118 |
2.16 depends on firefox. Earlier versions depend on seamonkey if USE=-firefox. |
119 |
|
120 |
HTH, |
121 |
-Richard |
122 |
-- |
123 |
gentoo-amd64@g.o mailing list |