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