Whether or not 'move' was the correct action in the recent compiz example, perhaps we need to consider that some times one package does actually make another obsolete. The correct thing for the PM to do is to first uninstall the obsolete package, then install the new one.
Now, it has been my experience that blocking dependencies are currently used to imply this "No, you have to remove cat/foo first before installing cat/bar instead" situation. This is somewhat annoying for me when I want to upgrade a bunch of packages, but I have to manually uninstall a few blockers first before this is possible. This could be automated by the PM in those cases with some sort of thing like this in the cat/bar-1.0.ebuild: OBSOLETES="cat/foo" Of course this would be a regular package atom (or list thereof), so it could be tied to specific versions of cat/foo. I suppose this could be seen as a special case of blocking deps which would automate a specific "cat/bar is to be preferred over cat/foo" However, I'm not exactly sure what you would do if you have pkg1 which depends on cat/foo and pkg2 which depends on cat/bar... -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm)
signature.asc
Description: PGP signature
