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] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |