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.