This is the mail archive of the
mailing list for the Cygwin project.
Re: [PATCH setup 00/14] Use libsolv, solve all our problems... (WIP)
- From: Ken Brown <kbrown at cornell dot edu>
- To: cygwin-apps at cygwin dot com
- Date: Wed, 13 Dec 2017 12:31:25 -0500
- Subject: Re: [PATCH setup 00/14] Use libsolv, solve all our problems... (WIP)
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <87poau9znx.fsf@Rainer.invalid> <email@example.com> <87ingltcn0.fsf@Rainer.invalid> <firstname.lastname@example.org> <email@example.com>
On 12/5/2017 9:32 AM, Jon Turney wrote:
It seems we're missing something to actually apply the default solution,
so "accept default solutions" makes no changes, at the moment. (looks
like we have to do this ourselves with solver_take_solution() ?)
I've just looked at this again, and I'm not sure what's happening.
Here's what I tried: I had two installed packages A and B, where A
requires B. I tried to uninstall B and got the expected problem report
telling me that A requires B. The solutions presented were
1. Uninstall A.
2. Don't uninstall B.
On the surface, it would seem that libsolv chose 2 by default, because
it returned an empty transaction list. This was reflected in the log
and was also clear when I selected 'Back'.
On the other hand, maybe libsolv's default was to do nothing, and it's
just a coincidence that this coincided with solution 2. This could have
tricked me into thinking that libsolv chose a default solution.
Also, in the dependency problem report, we should identify which of the
possible solutions is the default one, so it's clearer what "accept
default solutions" is going to do.
Is there in fact a default solution? I skimmed through problems.c in
the libsolv sources, and I didn't see any mention of a default solution.
Maybe we have to deal with this situation ourselves. Whenever a problem
involves a missing dependency, we could choose as default solution the
one that installs/keeps the dependent package, as is currently done.