Jim Ramsay wrote: > 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. > I don't think it was, for the reasons stated on the bug, and based on what Mr Mauch has just said.
> 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. > You can use a script to automate that [1] so it's just a question of pressing any key to unmerge (depending on the block; it might not actually apply by the time you come to the blocked app.) > 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 really like that idea. (A RECOMMENDS thing similar to debian would be nice too.) > 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... > That kinda sounds like the same issue genone was raising; since the difference upstream is tied to a version, whereas the Gentoo package names apply to all versions there can be no guarantee of compatibility. Maybe you could get round this by only using versioned deps. (So a package move script would have to ensure nothing had an unversioned dep on either package.) [1] http://forums.gentoo.org/viewtopic-t-546828.html New, improved-- shiny! ;D -- [EMAIL PROTECTED] mailing list
