On 27/09/2017 21:33, Ken Brown wrote:
On 9/27/2017 3:14 PM, Jon Turney wrote:
On 26/09/2017 17:06, Ken Brown wrote:
On 9/26/2017 10:50 AM, Jon Turney wrote:
On 15/09/2017 17:53, Ken Brown wrote:
On 9/15/2017 11:15 AM, Jon Turney wrote:
[...]
If we select 'curr', then the latest version of all installed
packages is selected by the picker and will be shown in the pending
view, and gets fed into the solver.
I guess this is technically wrong: really we should ask the solver
to do SOLVER_UPDATE | SOLVER_SOLVABLE_ALL, which will come up with a
solution which updates all installed packages to the latest possible
version, subject to any other constraints which exist.
I suspect there's no difference between these two at the moment,
though.
Not sure how to do this properly, though.
One possibility is that we feed all our information to the solver
before going to the chooser page. We could then present the solver's
initial solution in the pending view as the first thing the user sees.
Yes, this sounds about right.
Thanks to your work we kind of have a bidirectional conversion between
packagedb pick/desired state and a SolverTransactionList now, so this
should be possible.
(Although it should be done when the state of the 'Keep' or 'Current'
control changes - note that changing this setting clears any manual
picks currently. [and there's a mechanism to apply the initial state
of that control initially])
OK, I'll work on this. I'm traveling at the moment, but I should be
able to do it in a couple weeks.
Thanks, but that was more me thinking out loud. Since it seems pretty
straightforward, I've written this change.
I've rebased the topic/libsolv branch, with the following additional
changes:
* Applied your unrelated change to .gitignore to master
* Dropped a couple patches of mine which weren't supposed to escape yet.
* Squashed your "fix typo" patches into the patch they fix (I'm not sure
how I managed to make that typo in bootstrap.sh! :))
* Rather than add a parameter to SolvableVersion::depends() to make it
return obsoletes, I've factored out the key-to-deplist code as a helper
function, and added SolvableVersion::obsoletes(). (There may be other
deplist attributes in future, so this seems the sane way to do it.)
* Added handling of Source: lines in setup.ini
