| 1 |
On 6/20/19 12:02 PM, michael.lienhardt@×××××××.net wrote: |
| 2 |
> Dear all, |
| 3 |
> |
| 4 |
> A few months ago, I got back to my constraint-based dependency solver for portage, that I had to leave for a while. |
| 5 |
> Thanks to Zac Medico, it is now based on portage itself to query the portage tree, and so the code is far simpler (and far less buggy). |
| 6 |
> It is on github: https://github.com/gzoumix/pdepa |
| 7 |
|
| 8 |
Great! |
| 9 |
|
| 10 |
> I still have some work to do on the implementation, and with some colleagues, we are planning to publish it in a conference, with the related theory. |
| 11 |
> However, to have relevant information to publish, I need your help, if you could answer some questions that will come up during testing. |
| 12 |
> For instance, in all my tests, emerge (during its dependency resolution) always replaces atoms with the latest version of the pc that matches it, even with all possible backtracking options being selected |
| 13 |
> (I noticed this behavior because emerge failed installing a package such that the latest corresponding cpv could be installed, while the previous version could be). |
| 14 |
> Is it really the default behavior of emerge, and if yes, is there a way to make emerge consider all matching cpv for an atom? |
| 15 |
|
| 16 |
It's capable of considering older versions, but maybe there's some |
| 17 |
deficiency in the algorithm. We should analyze a specific example in |
| 18 |
order to understand the behavior. |
| 19 |
|
| 20 |
Maybe you're referring to this code which forces the highest version in |
| 21 |
the event of a conflict: |
| 22 |
|
| 23 |
https://gitweb.gentoo.org/proj/portage.git/commit/?id=a9064d08ef4c92a5d0d1bfb3dc8a01b7850812b0 |
| 24 |
|
| 25 |
> Thank you! |
| 26 |
> Michael |
| 27 |
> |
| 28 |
-- |
| 29 |
Thanks, |
| 30 |
Zac |
Archives