| 1 |
On 06/10/19 22:42, Rich Freeman wrote: |
| 2 |
|
| 3 |
> On Mon, Jun 10, 2019 at 5:39 PM n952162<n952162@×××.de> wrote: |
| 4 |
>> On 06/06/19 06:00,n952162@×××.de wrote: |
| 5 |
>> |
| 6 |
>> In trying to update portage (before I update my system), I have this: |
| 7 |
>> |
| 8 |
>> !!! All ebuilds that could satisfy ">=dev-python/setuptools-34[python_targets_pypy(-)?,pn_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_pypy(-),-pyth-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)]" have been mas |
| 9 |
>> !!! One of the following masked packages is required to complete your request: |
| 10 |
>> - dev-python/setuptools-9999::gentoo (masked by: EAPI 7) |
| 11 |
>> - dev-python/setuptools-41.0.1::gentoo (masked by: EAPI 7) |
| 12 |
>> - dev-python/setuptools-41.0.0::gentoo (masked by: EAPI 7) |
| 13 |
>> - dev-python/setuptools-40.9.0::gentoo (masked by: EAPI 7) |
| 14 |
>> - dev-python/setuptools-40.8.0::gentoo (masked by: EAPI 7) |
| 15 |
>> - dev-python/setuptools-40.7.3::gentoo (masked by: EAPI 7) |
| 16 |
>> - dev-python/setuptools-40.6.3::gentoo (masked by: backtracking: slot conflict) |
| 17 |
>> - dev-python/setuptools-36.7.2::gentoo (masked by: backtracking: slot conflict) |
| 18 |
>> |
| 19 |
>> Looking athttps://packages.gentoo.org/packages/dev-python/setuptools shows that the only two versions stable for am64 are 40.6.3 and 36.7.2. |
| 20 |
>> |
| 21 |
>> What is backtracking and how can I have a slot conflict if it's the developers who determine what version sits in a slot? |
| 22 |
> Backtracking refers to how the dependency resolver works - it couldn't |
| 23 |
> figure out a way to satisfy your requirements. You have a slot |
| 24 |
> conflict because two different packages that you asked for require two |
| 25 |
> different versions of setuptools to be installed at the same time in |
| 26 |
> the same slot, or at least that is what portage interprets what it is |
| 27 |
> finding. |
| 28 |
|
| 29 |
The verbose output (attached) says that the package with /"new SLOT |
| 30 |
installation (side-by-side versions)" /is: |
| 31 |
|
| 32 |
dev-lang/python-3.6.5:3.6/3.6m |
| 33 |
|
| 34 |
The version in /var/db/pkg/dev-lang/python-* is: |
| 35 |
|
| 36 |
/var/db/pkg/dev-lang/python-3.5.4-r1/python-3.5.4-r1.ebuild:SLOT="3.5/3.5m" |
| 37 |
|
| 38 |
That doesn't look like the same slot... |
| 39 |
|
| 40 |
How can there be a slot collision? If the developers say, slot 3 is for |
| 41 |
a particular version, why should anybody want to push anything else into |
| 42 |
slot 3? |
| 43 |
|
| 44 |
|
| 45 |
> I'd need to see more of the output to get a sense of what is |
| 46 |
> actually going on - posting 10 lines out of what was probably 1000+ |
| 47 |
> lines of output honestly doesn't help anybody to assist you. Yes, the |
| 48 |
> whole output is tedious but probably contains clues. |
| 49 |
|
| 50 |
Gladly! I've attached the output of this command: |
| 51 |
|
| 52 |
|
| 53 |
sudo emerge --verbose y --verbose-conflicts |
| 54 |
--verbose-slot-rebuilds --oneshot portage 2>&1 | tee |
| 55 |
emerge-portage-2.txt |
| 56 |
|
| 57 |
|
| 58 |
I presume that the flags in front of the dependency list are those given |
| 59 |
in the --pretend option of emerge(1) ... |
| 60 |
|
| 61 |
|
| 62 |
>> One might say, I have a package already dependent on setuptools and it's not the right one, but how can it be that two different versions want to go into the same slot? |
| 63 |
> There are many ways this can happen. Maybe package A wants setuptools |
| 64 |
> 40.7.3 or greater, and package B wants setuptools 40.6.3 or lesser, |
| 65 |
> and you asked for both. |
| 66 |
|
| 67 |
|
| 68 |
But isn't that exactly what slots are supposed to address? How can |
| 69 |
there be a conflict? A limited number of slots? |
| 70 |
|
| 71 |
|
| 72 |
> Often though it is an issue with not |
| 73 |
> backtracking enough - if you're doing a huge update often you need to |
| 74 |
> add --backtrack=100 or rarely even a larger value in order for portage |
| 75 |
> to find a way to meet the requirements. |
| 76 |
|
| 77 |
Can I follow the backtracking in this attached output somehow, to see |
| 78 |
what how backtracking works? |
| 79 |
|
| 80 |
|
| 81 |
> Sometimes you need to include |
| 82 |
> --with-bdeps=y because something portage isn't considering in-scope is |
| 83 |
> pulling in something that conflicts, and it could be resolved by |
| 84 |
> letting portage update more packages. |
| 85 |
> |
| 86 |
>> Backtracking is something to do with dependency checking. I haven't seen any explanation of what goes on in dependency checking and why backtracking is necessary. Can someone point to an explanation? |
| 87 |
> Basically your config files, like the world file, and the profile |
| 88 |
> system set, contain a list of stuff you want. Portage wants to give |
| 89 |
> you want you want. Maybe these files specify 200 packages you're |
| 90 |
> interested in directly. Each of these might ask for 5 more, and each |
| 91 |
> of those 5 more, and so on. Portage works backwards through the |
| 92 |
> dependency tree to generate a list of every requirement of every |
| 93 |
> package. These can form circular loops, and the tree can get quite |
| 94 |
> large very quickly. As an optimization I believe portage avoids |
| 95 |
> traversing the entire thing and only goes back so far - usually it can |
| 96 |
> find a solution to your requirements without traversing the entire |
| 97 |
> tree. |
| 98 |
> |
| 99 |
> |
| 100 |
|
| 101 |
I'm trying to understand that ... |
| 102 |
|
| 103 |
A -> + |
| 104 |
|
| 105 |
| |
| 106 |
+ -> B ->+ |
| 107 |
| | |
| 108 |
| + -> C[0] |
| 109 |
| + -> D |
| 110 |
| |
| 111 |
+ -> C[1] |
| 112 |
|
| 113 |
|
| 114 |
Okay, so backtracking is ... when I'm at C[1] and see there's already a C[0] ... |
| 115 |
Then I go back to B to see if it might be happy with C[1]? |
Archives