On 6/20/19 12:02 PM, michael.lienha...@laposte.net wrote: > Dear all, > > A few months ago, I got back to my constraint-based dependency solver for > portage, that I had to leave for a while. > 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). > It is on github: https://github.com/gzoumix/pdepa
Great! > 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. > However, to have relevant information to publish, I need your help, if you > could answer some questions that will come up during testing. > 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 > (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). > 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? It's capable of considering older versions, but maybe there's some deficiency in the algorithm. We should analyze a specific example in order to understand the behavior. Maybe you're referring to this code which forces the highest version in the event of a conflict: https://gitweb.gentoo.org/proj/portage.git/commit/?id=a9064d08ef4c92a5d0d1bfb3dc8a01b7850812b0 > Thank you! > Michael > -- Thanks, Zac
signature.asc
Description: OpenPGP digital signature
