Re: [PATCH setup 00/14] Use libsolv, solve all our problems... (WIP)

[Jon Turney <jon.turney@dronecode.org.uk>]

On 14/09/2017 21:46, Ken Brown wrote:
> On 9/14/2017 1:26 PM, Achim Gratz wrote:
>> Ken Brown writes:
>>> What I've been struggling with, however, is the UI.  But now that I
>>> think about it, maybe it isn't that hard.  It's just a matter of doing
>>> something reasonable if the user unchecks "Accept default problem
>>> solutions".  I'll see what I can come up with.
>>
>> Well, zypper pretty much just gives you a bunch of possible solutions
>> and asks you to select one if there is either more than one or the
>> otherwise preferred solution is blocked by a lock.  There is always one
>> "break <whatever> package by doing <stuff>" down that list.  You could
>> maybe offer something along those lines in the inevitable dialog box?
> 
> In the long run I think that's the way to go.  But implementing that is 
> more work than I feel like doing at the moment.  For now I've gone with 

Yeah, a better interface to the solution list would be nice, but 
:effort: and it's unclear how much use it would get with the loose 
requirements our current package database contains.

I'm not sure there is huge value in the current "don't install 
dependencies" option.  I don't know why anyone would want to do that, 
and it's just going to give you a broken install sometimes...

> an approach that was easier to program, more like the current setup.exe. 
>   If the solver finds problems (including missing dependencies), the 
> user has four choices on the Prerequisite page:
> 
> 1. Click Back to go back to the Chooser page, with the Pending view 
> showing the solver's default solutions.
> 
> 2. Click Next to accept the default solutions.
> 
> 3. Uncheck the "Accept default solutions" box and click Next.  If the 
> user dismisses the resulting warning, setup will go ahead and do what 
> the user requested.
> 
> 4. Cancel.
> 
> Once the inevitable remaining bugs are fixed, I think we'll have a 
> setup.exe that's better than the current one, with possibilities for 
> further UI improvements along the lines you suggested.

Thanks again for your work on this.

Can you rebase your and my patches onto master, and push to sourceware 
in a topic/libsolv branch?

After that, I think it might be useful to make a binary available for 
wider testing.

Two things I have left to look at:

- Since the distributed setup is cross-built on Linux, I need to look 
into making a RPM for the cross-built libsolv.

- Wire up the "Source:" (note capital 'S') lines in setup.ini.  These 
work in current setup versions (although we don't use it, but I'd like 
to change that).  Since the the source package might appear after the 
package in setup.ini, this seems to conflict with the current approach 
of storing the sourcepackage solvable id, which I did because searching 
the solver repo for a package by name was slow. With hindsight, this 
seems wrong.