Re: setup's response to a "corrupt local copy"
- Date: Fri, 15 Dec 2017 09:50:44 +0700
- From: Vince Rice <vrice@xxxxxxxxxxxxxxxxxxxx>
- Subject: 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:
> 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
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
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple