> On Dec 15, 2017, at 7:33 AM, Steven Penny wrote: > > On Thu, 14 Dec 2017 14:57:14, Ken Brown wrote: >> And, as I said, it happens when setup is *preparing* to download files and >> finds a corrupt copy already present in the local cache. In that context, >> setup has no idea where the file came from. > > the point is, *it doesnt matter*. it is not and shouldnt be setup.exe job to > worry about the origin of files in the Local Package Directory. > > Officially this directory, and the files below, are only created by setup.exe > itself. If people are creating their own custom archives, then putting them in > the Local Package Directory, *then* expecting them to work without a modified > setup.ini, that is an error in judgment on their part. > > my original point, and one that i stand by as ive seen no reasonable counter > yet, is that setup.exe should assume control of the entire Local Package > Directory and its contents. this includes removing rogue files that are in > conflict with the current setup.ini. As Hans said: > > http://cygwin.com/ml/cygwin/2017-12/msg00126.html > > my viewpoint would be in concert with a typical "Git" workflow: > > 1. make changes to working directory > 2. add those changes to the index > > with step 2 being the analogue to creating a custom setup.ini. setup.ini > should > always have the final say on what a correct file is; so if you want a custom > archive then you better tell setup.ini about it or otherwise risk it being > nuked.
No, the point is it doesn't matter *to you*. As always, what you want doesn't necessarily reflect what everyone else wants, no matter how often you repeat yourself or try to deflect others' opinions as not being a "reasonable counter". It's my computer. I don't want setup (or anything else) replacing files on it it doesn't know about without at least asking whether that's what I want it to do. Setup's current behavior is exactly what it should be, IMO. If, as has been mentioned, someone wants to offer an *option* to replace, either with or without a question, then great. But the default should be to leave something it doesn't know about alone. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
