Pardon me if this is a well-known thing,... I looked on the sticky threads and didn't see anything relevant.

I'm often frustrated recently because portage wants to build a lot more than I'm asking it for. Right now I'm trying to upgrade Firefox, and portage wants to upgrade a ton of other unrelated stuff at the same time, including Chromium and Libreoffice.

How do I stop this behavior? It seems this is "the new way of things". But occasionally I'll really wanna emerge just one thing and have only its actual dependencies upgraded along with it, not my kitchen sink.

Thanks, genstorm. I'm a little mystified that you don't seem to think this is the New Normal.... Apparently when dependencies are upgraded, other apps that depend on those are being rebuilt as well (and recursively onward??) I guess I understand the logic behind it, but I still don't want it to happen. I'd rather just be warned.

Ant P., you seem to be confirming my hunch in my previous post. The fact is, this never used to happen until, I dunno, 9 months to a year ago. Practically speaking, I want to prevent the recursive rebuilding, however recommended it may be (or be given the option to remove certain top-level packages like chromium from the rebuild list). Can I do that? Or am I just stuck? I have older, slower h/w and a not-super-fast Internet link, so this is really troublesome.

I don't remember just when the feature got added, but I looked forward to it with great anticipation before it came. Updates--either updates to specific packages or world updates--often trigger updates to dependencies. These latter updates very often result in removals of sonames that other packages need.

This meant that nearly every time after an update you would need to run revdep-rebuild so that other packages broken by the library upgrade would work again.

In your case, when you upgraded Firefox, you triggered upgrades to libgcrypt, libexif, and icu that resulted in new sonames for those libraries. If then you tried to run a program linked to an older version of one of these libraries (as Chromium was, for instance), it would fail to load.

We used to have to go through the dreary task of running revdep-rebuild all the time after an upgrade. Oftentimes when I ran it I found that I didn't really need to do so. Now Portage figures out when programs depending on upgraded libraries would break because of a soname change and schedules them for rebuild.

This means that, yes, you're going through just the same kind of package rebuilding as you did before this Portage change--and you get it without having to run revdep-rebuild. I call it a big win.

Ant P., you seem to be confirming my hunch in my previous post. The fact is, this never used to happen until, I dunno, 9 months to a year ago. Practically speaking, I want to prevent the recursive rebuilding, however recommended it may be (or be given the option to remove certain top-level packages like chromium from the rebuild list). Can I do that? Or am I just stuck? I have older, slower h/w and a not-super-fast Internet link, so this is really troublesome.

Basically, portage prevents you from a broken state._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

Still, I think it would be good to allow the user to proceed while postponing some of the rebuilds, for cases where they really need to upgrade package X and simply don't have time and resources to finish the whole job at once.

Ant P., you seem to be confirming my hunch in my previous post. The fact is, this never used to happen until, I dunno, 9 months to a year ago. Practically speaking, I want to prevent the recursive rebuilding, however recommended it may be (or be given the option to remove certain top-level packages like chromium from the rebuild list). Can I do that? Or am I just stuck? I have older, slower h/w and a not-super-fast Internet link, so this is really troublesome.

This is the new EAPI=5 subslot feature. It allows an ebuild to specify that it needs to be rebuilt when a library it depends on becomes ABI-incompatible by an update. This means that (in an ideal world) you will never again need to run revdep-rebuild and that you will never again have a broken system due to library versioning issues.
In this case, llibmspub, and gnupg are being rebuilt because a dependent library will be updated which will break that package. icu, libgcrypt, libxslt, and libreoffice-bin have the same issue but also happen to have a new version available.
You could skip a package you don't want to rebuild now by simply adding --keep-going to your emerge command line and doing something like 'sudo killall make' when the package you want to skip is being built. Afaik that's the only way, and be advised that this will leave your system in a potentially incoherent state, i.e. you MUST run revdep-rebuild.

Still, I think it would be good to allow the user to proceed while postponing some of the rebuilds

I suppose that you can do this with --exclude. However, you should be aware that after the upgrade the excluded packages might no longer work (and if you exclude some libraries even your "main" package might fail to work due to this).

Using --exclude, portage will complain that required ebuilds are not available._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

Using --exclude, portage will complain that required ebuilds are not available.

Even for subslot-dependencies like libreoffice? I am surprised, but I admit that I did not verify it.
Anyway, you can use --ignore-built-slot-operator-deps=n to ignore all these subslot-dependencies, but this is dangerous, of course.
As a last resort, if you know what you are doing, you can explicitly use -O and list all packages you want to upgrade.

Using --exclude, portage will complain that required ebuilds are not available.

Even for subslot-dependencies like libreoffice? I am surprised, but I admit that I did not verify it.

Out of experience, I would think that should result in a conflict between installed and to-be-merged packages._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic