On 11/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I have a ~amd64 system on which I am trying to emerge world.
First, what are the proper options to pass to this command?
Nobody here can actually answer that question, because it depends on
what, exactly, you want to do. However, some common option
cominations, and their effect, would be:
"emerge world": updates only packages that are explicitly listed in
/var/lib/portage/world.
"emerge --update world": same as above, but also updates *direct*
dependancies of those packages.
"emerge --deep --update world": same as above, but updates *all* dependancies.
"emerge --deep --update --newuse world": same as above, but will also
rebuild packages where the defined or configured USE flags have
changed.
As for which is the most appropriate for you, well:
--deep ensures you get all of the very latest updates for everything.
Well, /almost/ everything [1]. The downside of this is that you have
a lot more updating to do, and library updates can break dynamic
linking of some programs requiring them to be rebuilt with
revdep-rebuild. Not surprisingly, opponents of --deep typically cite
system and ABI stability as arguments against using --deep.
--newuse is almost always a good idea, and certainly "required" after
making changes to your USE in make.conf or package.use.
Second, when I try emever -pve world, I get the following complaints:
Calculating world dependencies
..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ... done!
[blocks B ] kde-base/kde-env (is blocking kde-base/kdelibs-3.5.5-r5)
[blocks B ] >=kde-base/kdelibs-3.5.4-r2 (is blocking kde-base/kde-env-3-r4)
kde-env is not required (and is in fact incompatible) with the new
kdelibs. Do "emerge -C kde-env" to remove kde-env and resolve these
[blocks B ] www-client/mozilla (is blocking www-client/seamonkey-1.0.6)
see below...
[blocks B ] <dev-python/pygtk-2.9 (is blocking dev-python/pygobject-2.12.2)
You have some version of pygtk earlier than 2.9 installed, which
conflicts (e.g. by installing duplicate files, etc) with pyobject.
Basically, you need a ~arch version of pygtk to go with your ~arch
pyobject.
This happens aperiodically. Some new package obsoletes another
package, but nothing documents it, nothing tells me what to do.
/usr/portage/cate-gory/package/ChangeLog should document when the
block was added, usually with a bug# that you can reference on
bugs.gentoo.org. But as far as telling you what to do, well, *gentoo*
*doesn't* *do* *that*.....*ever*! ;-P
How you handle a block is entirely up to you.
Do I unmerge the existing package and install the new one?
That is certainly one option. You could also mask the new one in
/etc/portage/package.mask. If it is a version block, you might need
to update to a newer (or downgrade to an older) version of a package.
3. Mozilla vs Seamonkey. I tried Seamonkey a couple of times, and it
crashed so often and so quickly that I reverted to mozilla. Now it
seems there are quite a few packages which insist on seamonkey and
are not satisfied with mozilla.
You will have to give an example of this. I certainly don't have
seamonkey installed on either of my ~arch systems, and I have a good
number of packages installed on both.
If the packages have USE flags, check them. Something with a
"firefox" flag might use that to prefer firefox over seamonkey.
Something else with a "no-seamonkey" flag...well, guess what that
does. TIP: add --verbose --pretend to your emerge commands to see the
USE flags and changes. And add --tree to see what is pulling in
seamonkey.
Why do some packages explicitly care about seamonkey? Shouldn't
they be pretty much the same? Shouldn't the dependencies be happy
with either one?
In the meantime, is there some way to convince emerge that
seamonkey has been installed and to not get its knickers in a
twist?
man emerge, /package.provided. But this is probably overkill, I think
you just don't have your USE flags set the way you want.
I suppose I could always unmerge mozilla, emerge world,
unmerge seamonkey, and emerge mozilla again, but I get tired of
having to kick out half a dozen packages like totem
totem depends on seamonkey if you have USE="+nsplugin -firefox"...
gedit,
No direct dependancy on seamonkey here
gnome-base
No such package...did you mean gnome-base/gnome? If so, again, no
direct depend here
epiphany
2.16 depends on firefox. Earlier versions depend on seamonkey if USE=-firefox.
HTH,
-Richard
--
[email protected] mailing list
