Earlier today, I ran head-first into my first serious emerge block: Portage refuses to update because it is blocked by logrotate.

The ‘standard’ way to resolve a block is to unmerge whatever’s blocking Portage (logrotate in this case), update Portage, then re-emerge the unmerged package.

Problem is: logrotate is a dependency of squid, and the squid must not be interrupted. If I think about it, unmerging logrotate should not disturb squid. After all, logrotate only rotates squid’s log; no other functionality whatsoever. But at the moment I was just too dumbstruck about how is it possible for logrotate to block Portage. Besides, the squid is being used by about 20+ people, so in the slim-but-not-nil possibility that unmerging logrotate might interfere with squid, I decided to ‘play it safe’ and not unmerging squid.

I brought my conundrum to the gentoo-user list at l.g.o (hi guys!), where Walter Dnes suggested I upgrade Portage first, in the hope that the latest Portage has additional tricks up its sleeve to handle this blockage.

No dice. Specifying emerge portage still resulted in the same blockage.

I almost give up hope. But a last-ditch Google-fu attempt landed me on two very hintful pages: Bug 374287 and the p.g.o page on logrotate.

Those two pages led me to my also-last-ditch attempt to fix the blockage: I tried emerge -D logrotate, after adding the necessary >=sys-apps/logrotate-3.8.0 ~amd64 entry into package.keywords.

Whaddaya know! logrotate gets updated successfully! Buoyed by my small success, I continued with emerge -avuDN @world, and…

Hallelujah! There’s joy in Mudville!*

No more blocking, and emerge chugs along merrily as it downloaded, compiled, and installed @world updates :)

So, moral of the story: When faced with a blockage — especially one involving Portage — don’t hesitate to upgrade the blocking package first.

Thanks for reading. Until the next dispatch, keep strong!