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] Revert "Don't override a Keep selection"

On 10/19/2017 11:05 AM, Ken Brown wrote:
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.
---     | 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 conflict?

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 from setup.

I'll prepare a new patch that restores the SOLVER_LOCK functionality that was inadvertently removed in commit ff0bb3d.

Attached. I kept making mistakes while doing this, so I hope I got it right in the end.

Here's a related question. Currently if libsolv decides I should install something and I choose Skip instead, it will get installed anyway (with no problem report). Maybe we should have a taskSkip that generates a SOLVER_LOCK in that case, analogous to taskKeep?


Attachment: 0001-Fix-the-functionality-of-taskKeep.patch
Description: Text document

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