Why does portage want to upgrade everything?

[Punchcutter]

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.

Is there any way I can force portage to back off? Thanks.

[asturm]

Could you show us what you are actually doing, and portage's output?

[Punchcutter]

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.]

The simple answer is some of those ebuilds no longer exist.
The complex answer is at the bottom of that output.

[Punchcutter]

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.

[miket]

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.

[asturm]

[Punchcutter]

OK, miket, you've convinced me to take the medicine and like it

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.

[Aquous]

[mv]

[asturm]

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

[mv]

[asturm]