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@lists.gentoo.org mailing list
