public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Vince Rice <vrice@solidrocksystems.com>
To: The Cygwin Mailing List <cygwin@cygwin.com>
Subject: Re: setup 2.883 release candidate - please test
Date: Wed, 13 Dec 2017 05:21:00 -0000	[thread overview]
Message-ID: <D097F9F9-288E-4353-83B8-E2C370B0428B@solidrocksystems.com> (raw)
In-Reply-To: <5a307086.70159d0a.91426.1547@mx.google.com>

> On Dec 12, 2017, at 6:12 PM, Steven Penny wrote:
> 
> On Tue, 12 Dec 2017 08:04:09, Ken Brown wrote:
>> How can setup possibly automate this?  It doesn't know where the corrupt local tarball came from.  For example, suppose you sometimes build packages yourself for testing or debugging.  You keep them in your local repository, and you also upload them to a private repository on the internet so that you can easily install them on a different computer. You make a change and rebuild the package, but you forget to replace all copies of it.  setup can't know which version is the correct one.  And it certainly shouldn't be deleting your files because it thinks they're corrupt.
> 
> No, this is not right. If you are building packages yourself, then you should
> have a custom setup.ini to match, example:
> 
> http://matzeri.altervista.org/x86_64
> 
> so that in any case, setup.ini has the final say of what a correct archive is,
> via the SHA512. If a file in the local repo doesnt match either because:
> 
> - file size 0
> - file size less than proper size because of interrupted download
> - SHA mismatch because of custom build
> 
> said file should be removed and redownloaded by setup.exe. if you are building
> custom archives, then you should also be making custom setup.ini.

Where is that stated as a requirement? I don't see it anywhere, and I don't agree that it should be one. Ken is correct on this, IMO.
--
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

  reply	other threads:[~2017-12-13  3:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-11 21:11 Jon Turney
2017-12-12  6:53 ` Steven Penny
2017-12-12 14:15   ` Ken Brown
2017-12-13  4:09     ` Steven Penny
2017-12-13  5:21       ` Vince Rice [this message]
2017-12-13  7:50         ` cyg Simple
2017-12-13 14:33           ` Ken Brown
2017-12-15  0:32 ` Achim Gratz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D097F9F9-288E-4353-83B8-E2C370B0428B@solidrocksystems.com \
    --to=vrice@solidrocksystems.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).