| 1 |
Jim Ramsay wrote: |
| 2 |
|
| 3 |
> Whether or not 'move' was the correct action in the recent compiz |
| 4 |
> example, perhaps we need to consider that some times one package does |
| 5 |
> actually make another obsolete. The correct thing for the PM to |
| 6 |
> do is to first uninstall the obsolete package, then install the new one. |
| 7 |
> |
| 8 |
I don't think it was, for the reasons stated on the bug, and based on what |
| 9 |
Mr Mauch has just said. |
| 10 |
|
| 11 |
> Now, it has been my experience that blocking dependencies are currently |
| 12 |
> used to imply this "No, you have to remove cat/foo first before |
| 13 |
> installing cat/bar instead" situation. This is somewhat annoying for |
| 14 |
> me when I want to upgrade a bunch of packages, but I have to manually |
| 15 |
> uninstall a few blockers first before this is possible. |
| 16 |
> |
| 17 |
You can use a script to automate that [1] so it's just a question of |
| 18 |
pressing any key to unmerge (depending on the block; it might not actually |
| 19 |
apply by the time you come to the blocked app.) |
| 20 |
|
| 21 |
> This could be automated by the PM in those cases with some sort of |
| 22 |
> thing like this in the cat/bar-1.0.ebuild: |
| 23 |
> |
| 24 |
> OBSOLETES="cat/foo" |
| 25 |
> |
| 26 |
> Of course this would be a regular package atom (or list thereof), so it |
| 27 |
> could be tied to specific versions of cat/foo. |
| 28 |
> |
| 29 |
I really like that idea. (A RECOMMENDS thing similar to debian would be nice |
| 30 |
too.) |
| 31 |
|
| 32 |
> I suppose this could be seen as a special case of blocking deps which |
| 33 |
> would automate a specific "cat/bar is to be preferred over cat/foo" |
| 34 |
> |
| 35 |
> However, I'm not exactly sure what you would do if you have pkg1 which |
| 36 |
> depends on cat/foo and pkg2 which depends on cat/bar... |
| 37 |
> |
| 38 |
That kinda sounds like the same issue genone was raising; since the |
| 39 |
difference upstream is tied to a version, whereas the Gentoo package names |
| 40 |
apply to all versions there can be no guarantee of compatibility. Maybe you |
| 41 |
could get round this by only using versioned deps. (So a package move |
| 42 |
script would have to ensure nothing had an unversioned dep on either |
| 43 |
package.) |
| 44 |
|
| 45 |
[1] http://forums.gentoo.org/viewtopic-t-546828.html |
| 46 |
New, improved-- shiny! ;D |
| 47 |
|
| 48 |
|
| 49 |
-- |
| 50 |
gentoo-dev@g.o mailing list |
Archives