Ciaran McCreesh schrieb:
> What all are blocks used for?
> 
> a) Marking that two unrelated packages are mutually incompatible at
> runtime because they happen to collide, for example on a commonly named
> executable.
> 
> b) Marking that two related implementations are mutually incompatible at
> runtime because they both provide the same binary.
> 
> c) Marking that a file that used to be provided by one package is now
> provided by another package that is either depending upon or depended
> upon by the original package.
> 
> d) Marking that a package has been moved into another package.
> 
> Are there any other uses?
> 
> For future EAPIs, being able to tell the package manager that your
> block is of one of the types above will help the package manager smooth
> out the upgrade path for users. For example, for class d) blocks such
> as the recent coreutils / mktemp mess, the package manager can suggest
> to the user to install the new package and then uninstall the old
> package, rather than forcing the user to uninstall the old package by
> hand (possibly leaving their system without critical utilities) and then
> install the new package.
> 
> I strongly suspect that in many (but not all) cases the package manager
> could be making users' lives a lot easier than it currently is...
> 
There is another case.

e) A package needs a newer version of another package, but doesn't depend on it.

This was the case with KDE4. kdelibs-4.0.x block these packages:
     !<kde-base/kdebase-3.5.7-r6
     !<kde-base/kdebase-startkde-3.5.7-r1
     !=kde-base/kdebase-3.5.8
     !=kde-base/kdebase-3.5.8-r1
     !=kde-base/kdebase-3.5.8-r2
     !=kde-base/kdebase-startkde-3.5.8

The reason is, that a newer revision has to be installed. (But of course 
kdelibs-4.0.x can't depend on a kde3 package.)
So in this case the behaviour would be different ((keyword and) upgrade one 
package, then install the other package) and the given block reason would be 
different.
-- 
gentoo-dev@g.o mailing list