1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Zac Medico wrote: |
5 |
> |
6 |
>> what I am going to propose here is a resolution strategy for this |
7 |
>> (although this whole thing simply tells me that portage misses some |
8 |
>> knowledge about the problem, like for example that dependencies should |
9 |
>> be enforced only at transaction boundaries, or simply that we have a |
10 |
>> class of dependencies that is irrelevant while system is in transient |
11 |
>> state) |
12 |
>> |
13 |
>> but, without trying to introduce overcomplicated solutions, as an |
14 |
>> user, I could solve the initial problem very easily: |
15 |
>> resolution strategy for it is to unmerge the old synce-0.13 packages, |
16 |
>> then the user will be able to install 0.14 packages. |
17 |
> |
18 |
> As said above, the problem is in the synce-gnomevfs-0.13 |
19 |
> dependencies, and there's nothing portage can do to change that. |
20 |
> |
21 |
|
22 |
ok, after discussion on IRC came out that the SynCE 0.14 suite didn't |
23 |
include a synce-gnomevfs-0.14 package (so it has implicitly needed to |
24 |
be uninstalled the old 0.13 version). |
25 |
|
26 |
unfortunately portage doesn't handle this situation automatically. |
27 |
|
28 |
I had to add a !app-pda/synce-gnomevfs dep to synce-0.14. |
29 |
this will be never handled automatically by portage unfortunately, |
30 |
because synce-gnomevfs has no reverse-depend on anything (my fault!), |
31 |
so a user generally puts into the world set. |
32 |
|
33 |
the user will see a blocker when upgrading, but that's little pain. |
34 |
|
35 |
cheers |
36 |
|
37 |
- -- |
38 |
Federico Ferri |
39 |
-----BEGIN PGP SIGNATURE----- |
40 |
Version: GnuPG v2.0.11 (GNU/Linux) |
41 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |
42 |
|
43 |
iEYEARECAAYFAkp5/sIACgkQV/B5axfzrPsIvgCfUFlEIwfZRsFxsMIKwrCzxwUQ |
44 |
rAcAnAsj9ej5d4n14LqjL7/tvLAwAv7z |
45 |
=hOZH |
46 |
-----END PGP SIGNATURE----- |