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

[Ken Brown <kbrown at cornell dot edu>]

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