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

[Ken Brown]

On 9/15/2017 4:56 PM, cyg Simple wrote:
> On 9/15/2017 12:53 PM, Ken Brown wrote:
>> On 9/15/2017 11:15 AM, Jon Turney wrote:
>>> On 08/09/2017 19:54, Ken Brown wrote:
>>>> Finally, I have a question for you, Jon: You introduced
>>>> PrereqChecker::upgrade, which is true if and only if the user selects
>>>> Current or Test.  I don't see why this is needed.  I've disabled the
>>>> use of it and haven't noticed any ill effects.  Am I missing something?
>>>
>>> This is supposed to be passed into SolverSolution::update() and used
>>> to determine if a SOLVER_UPDATE | SOLVER_SOLVABLE_ALL task is given to
>>> the solver, causing all packages to be updated (if possible) (i.e. so
>>> 'Keep' doesn't update anything)
>>
>> I've already arranged (by using SOLVER_LOCK) that 'Keep' doesn't update
>> anything.  So I don't think we need to worry about that case.  On the
>> other hand, if 'Current' or 'Test' is selected, then we already upgrade
>> as appropriate in the task list sent to the solver, so I don't think
>> it's necessary to send SOLVER_UPDATE | SOLVER_SOLVABLE_ALL to the solver
>> in that case either.
>>
>> Anyway, as I said, I've already disabled the use of
>> PrereqChecker::upgrade.  More precisely, I've changed
>> SolverSolution::update so that it never sends SOLVER_UPDATE |
>> SOLVER_SOLVABLE_ALL.  As a result, PrereqChecker::upgrade is simply
>> ignored, and everything seems to be working OK.
>>
> 
> Since this discussion appears to resolve around "test" versus
> "production" releases

No, it's simply a technical discussion about a new implementation of 
setup's dependency checker.

> would it not be better served if there were two
> differing base paths, one for production and one for test?  If that
> occurred then there may be more testers as what is used for production
> isn't borked by a test version of some package or even Cygwin itself.
> 
> So for example C:\cygwin64 serves the production path while
> C:\cygwin64test serves the test path.  This would help segregate test
> from a production environment without worrying the user with needing to
> revert back if something fails.

I'm not sure what you're suggesting.  Anyone is free to create two 
different Cygwin installations and use one of them for testing.  In 
fact, I do that all the time.  But I don't see that this is something 
for setup to manage.

Ken