This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]