Vladimir G. Ivanovic posted
<1144775349.12957.28.camel@...>, excerpted below,  on
Tue, 11 Apr 2006 10:09:09 -0700:

> On Tue, 2006-04-11 at 17:08 +0200, Simon Stelling wrote:
> 
>> In case you wonder why emerge -uD world shows you a block, note bug
>> 123526 [1]. It's as easy to resolve as every other block:
> 
> It's not obvious to me which package (in general) should prevail.
> 
> I'm leery of simply unmerging the blocking package to make way for the
> blocked package. Is it always the case that the blocked package is a
> drop-in replacement for the blocking package? Would such a blocking
> scenario every happen with, say, glibc?

It's not always the case, no.  As for glibc, not likely, unless you try to
emerge the gentoo-fbsd libc or something equally strange.  Even then, it'd
be more than a blocker, as that's setup by the profile, so you'd be
changing your profile as well.  Basically, there'd be several BIG FLASHY
WARNINGS and refusals to go forward unless you manually overrode things,
such that such a thing is not something you have to worry about doing
accidentally.  (Well, I've read of folks doing some pretty stupid stuff
when drunk or high, but other than that...  Just don't go sysadmin-ing
while under the influence!  =8^)

Blockers denote packages that stomp on each other if you try to merge both
of them.  It's portage's way of saying, "Hey, you can't merge that if this
package you already have (or that's a dependency of something else you are
merging) is already merged!  Choose one or the other, but you can't have
both, or bad things will happen!"

A blocker is often set when a package forks, and the two separate packages
still contain many of the same files and/or use the same config, but the
two different versions of the conflicting files are incompatible.
Alternatively, it might not be direct forks, but two packages providing
similar functionality.  An example would be some of the various cron
packages, which block each other.

In our particular case, linux32 vs. setarch, the two packages provide the
same functionality and many of the same files, so if you merge one, it'll
overwrite the files of the other.  Setarch, however, is a global package
that's more flexible than linux32, as it can be used for all the various
multilib archs (amd64, sparc, mips, ppc, etc), and can handle applications
such as double-chroots where you run a 64-bit chroot inside a 32-bit
chroot on a 64-bit native system.  The old linux32 was somewhat arch
flexible, but as written was hardcoded (according to the bug) to 32-bit,
so one could do the single chroot thing with it, but not the double chroot
thing, 32-bit on 64-bit OK, 64-bit in 32-bit on 64-bit not so.  Thus, the
old linux32 package will eventually be removed (after a suitable
switchover time), while setarch provides the same functionality (including
a linux32 symlink) and more.

That's why blockers are set up the way they are, to tell the sysadmin
about the problem and let them decide, rather than to arbitrarily make the
decision.  If it was always a direct dropin replacement (as here), portage
could just go ahead and do it (perhaps with the standard 10-second serious
ebeep warning), instead of bothering the admin.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list