Web lists-archives.com

Re: setup's response to a "corrupt local copy"

> 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