This is the mail archive of the
mailing list for the Cygwin project.
Re: [PATCH] Revert "Don't override a Keep selection"
On 10/18/2017 11:01 PM, Ken Brown wrote:
On 10/17/2017 3:31 PM, Ken Brown wrote:
On 10/17/2017 2:43 PM, Jon Turney wrote:
On 16/10/2017 20:13, Ken Brown wrote:
This reverts (the rest of) commit b43b697. Part of that commit was
already reverted in commit ff0bb3d. The rest is not needed either
since we no longer send the upgrade flag to the solver after the user
has made their selections.
libsolv.cc | 14 +++-----------
libsolv.h | 1 -
package_meta.h | 2 --
3 files changed, 3 insertions(+), 14 deletions(-)
Hmm... not sure about this.
Say the initial upgrade solution had something like: package A 1.0 ->
1.1, and A 1.1 has a dependency on package B 2.0, where currently B
1.0 is installed (so B 1.0 -> 2.0)
If the user then changes B to 'keep' (at 1.0), we should report a
Good point. I wasn't thinking about dependencies with version relations.
I just tested this scenario, and it turns out that putting a lock on B
1.0 overrides the dependency of A 1.1 on B 2.0. There's no problem
reported. On the other hand, if there's no lock, then the dependency
overrides the Keep choice, again with no problem reported.
Back to the drawing board.
Thinking about this further, using SOLVER_LOCK is probably the right
thing to do in this situation, even if no problem is reported. We can't
insist that users install the recommended version. For example, if I
choose to downgrade binutils while keeping the current gcc, then I'm
responsible for any breakage this might cause, with or without a warning
I'll prepare a new patch that restores the SOLVER_LOCK functionality
that was inadvertently removed in commit ff0bb3d.